IETF 47, Adelaide, Australia AAA WG Minutes Chairs: Bernard Aboba, Paul Krumviede Recorded by: Dave Mitton 3:30pm, Thursday, Mar 30th, 2000 The meeting started off with agenda bashing. John Vollbrecht agreed to present the IRTF report. Document status update We then had a summary of the status of requirements documents: AAA Network Access requirements is in AAA WG last call Mobile IP AAA requirements are about to go to Mobile IP WG last call Nasreq Criteria are in NASREQ WG last call Accounting documents: Accounting attributes draft is currently in AAA WG last call Accounting Management draft is undergoing revision and will go through AAA WG last call again --- Dave Mitton then gave an update on the NASREQ requirements document. Nasreq has updated their Requirements Criteria document per discussions at the AAA Interim Meeting. The new draft has been put out for WG last call. Tom Hiller made a presentation on TIA 45.6 requested updates to the network access requirements draft. The issues had to do with a few "shoulds" that TIA 45.6 considered as "musts”. It was agreed minor differences would be captured in footnotes for completeness. In all cases there were already "musts" in these rows in the other columns, so these are minor issues. The items are: Section 5.1 Data object confidentiality (e): M Certificate Transport (g): M Section 5.2 NAI Support (a): M Section 5.3 RADIUS Gateway (b): M Section 5.4 Accounting Time Stamps (e): M PatC: There was a problem when merging the TIA 45.6 column with Mobile IP, because MobileIP has Should for several of these requirements. Certificate Transport is a Must for TIA 45.6. NAI Support is also a Must for TIA 45.6. CharlieP: MIP doesn't require an NAI, since it works without it. Therefore the Mobile IP column cannot have a MUST for NAI. Tom Hiller: specific scenarios may not require it, but this is required feature for TIA 45.6. So we believe it is a MUST. Question: Why is CHAP support of Mobile IP optional? Answer: Because it isn’t mentioned in RFC 2002! Question: Why is RADIUS gateway support optional? Shouldn’t this be a MUST? Shouldn’t an accounting timestamp be a MUST? Question: We took the CDMA2000 column out to simplify the document. Should we put it back in? Answer: No, just footnotes the differences. Question: should we have a “phantom” fifth column of existing practices? Is there is anything missing that currrent vendors are using? Answer: the requirements document does not attempt to encompass all “extended practices”, on those that were felt to be important by the NASREQ, ROAMOPS, TIA 45.6 and Mobile IP WGs. John Volbrecht comments that the requirements were missing a description of encryption groups and aggregation capability. Paul Krumviede requested that this issue be taken this to the mailing list. Where do we go next on network access requirements? The next step of the process is to put the network access requirements document through WG last call again after the requested changes are incorporated, since they are substantive. In general, editorial changes and clarifications will be handled while the group progresses with the new work. We don't want to hold the group from moving forward. --- Alan Blount - Accounting Attributes Pat Calhoun mentioned a number of issues with the DIAMETER section of the draft and promised to send comments on the document to the list before the last call expired. --- Dave Harrington discussed the changes to the Accounting Management draft, which focused on use of SNMP for Accounting. Dave asserted that SNMP was not designed for Inter-Domain accounting, and so figuring out how this could be done is tricky. There may be a way in SNMP v3 to handle inter-domain accounting using contextName. The draft currently discusses use of proxies, contextEngineID (not practical) and using the domain as an index (requires new MIBs). Use of contextName should enable backwards compatibility with existing MIBs, although it does require SNMP v3. The next revision of the draft will cover this. Since there will be substantitive changes in the -02 draft, the document will go to Last Call again. --- Charlie Perkins - AAA in Ipng draft-ietf-perkins-aaav6-00.txt Charlie Perkins talked about how Ipv6 mobility might use AAA. He noted that there is no Foreign Agent in Ipv6,and so it is necessary to define mobile node behaviors/mechanisms to establish and control service access in v6 networks. Current thinking is that there is a Mobile Node NAI extension to router solicitation, and a AAA reply included in the Router Advertisement. Question: Are there any new requirements that came out of this work that would require us to modify the AAA Requirements document? Answer: it appears not. There was some discussion on use of DHCP with Mobile IP. This was brought up in the DHC WG. The issue is that the current DHCP authentication draft does not support AAA well, for either intra or inter-domain use. The problem is that the DHCP authentication option requires both the client and server to sign the immutable portions of the DHCP packet. However, the DHCP server cannot typically validate the DHCP authentication option because it doesn’t have access to cleartext passwords. Validating this via AAA requires that the DHCP server include the entire DHCP packet since this is required to validate the authentication option signature. The DHCP server must also send the AAA server its proposed reply so that the AAA server can use the password to sign the packet via the DHCP authentication option. This requires more knowledge of DHCP than a AAA server is likely to have. The same issues were encountered with support for Mobile IP in RFC 2002, which is why we have the mobile node NAI extension and Challenge-Response extensions. Addressing the problem will require that DHCP Authentication support challenge/response authentication. Bernard will work this and other issues with the DHCP group. Further discussion should be taken to the Mobile IP and DHC WG mailing lists. --- Chartering discussion The proposed new charter focuses on evaluating AAA protocol submissions and deciding whether to base the group’s work on one of them or to design a new one. There was discussion on the WG mailing list about how to move up the schedule, since there is still an urgent need for results in AAA WG. Looking at the schedule, IETF 48 is July 30 - August 4, and the submission deadline is July 14, 2000. Since there are various national holidays in July, as a practical matter, it would be necessary to have an evaluation document most complete by the end of June. If a protocol solicitation is sent out soon and protocol submissions were required by mid-late May or early June, this leaves just about enough time to complete the evaluation in time to discuss it at IETF 48. It is hard to see how things can be done faster. Goal Re-Charter by April Draft Schedule: - April ?: Call for submissions - May ?: Submission deadline (Protocol+ Compliance Description) - May ?+X: First draft of independent evaluation document - July 4th; Holiday - July 14: Submission deadline - July 30: August 4, IETF 48, Pittsburgh - August: Selection of protocol or decision to start from scratch - Sep: WG closes and re-charters [Editor’s note: Subsequently the Submission deadline was set to be June 1, 2000]. David Harrington: We want to make sure that existing protocols are considered and not necessarily a new single protocol be designed. The wording should be changed. It was noted that the protocol solicitation will require that authors give up change control to the IETF and submit an unqualified RFC 2026 statement. It was also noted that authors should submit a Compliance Description. This will make the evaluation easier. There was discussion on whether submission as an Internet Draft is required. There were no objections to a charter along these lines. Paul and Bernard will implement. --- IRTF RG Report - John Vollbrecht John Vollbrecht gave a short summary of the IRTF RG progress. There was also a meeting of the IRTF WG at this IETF. Done - 5: 23pm Since all work was completed at a single meeting, there was no meeting on Friday.