Editor's note: These minutes have not been edited. ROAMOPS WG Minutes 37th IETF, San Jose Reported by Glen Zorn (Microsoft) from notes by Pat Calhoun (US Robotics). The original agenda included the following items: Agenda bashing Certificates vs. Proxy Chaining NAI Formats Phone books What's next? During the agenda bashing period, the following items were added to the agenda: Accounting Document Status Mobile IP Support? PAP/CHAP as stated in draft-ietf-roamops-roamreq-00.txt Distributed Authorization Phone Book and Scripts The chairs requested that agenda suggestions be made in advance for future meetings. Bernard Aboba gave a couple of presentations on the Network Authentication Identifier (NAI) and the use of public-key certificates versus chaining proxies for inter-ISP authentication. Proxy Chaining vs. Public-key Certificates Proxy chaining has the advantage of being supported by the RADIUS protocol as it exists today, but does not provide for the non-repudiation of either authentication or accounting, requires manual maintenance of configuration files and/or authentication routing and may not work over multi-hop chains due to excessive timeouts. Certificates provide for non-repudiation of both authentication and accounting; allow automated maintenance of roaming organizations (joining, revoking membership); do not require an authentication routing scheme (any member can contact any other member without needing a shared secret). On the other hand, the use of public-key certificates would require modification to RADIUS (or at least to RADIUS proxies), and there is some question whether RADIUS could be used to transfer certificates , given its limit on attribute size. No existing RADIUS proxies support the use of certificates. In addition, certificates still require verification of a chain of trust and incur considerable processing overhead. The question was raised whether IPSEC should be used as the security mechanism inter-ISP instead of what RADIUS currently uses. If so, the overhead could cause a scalability problem, and PAP would not work with IPSEC. After some discussion, the group decided to take the issue to the mailing list. Network Authentication Identifier Bernard Aboba proposed the following requirements for an NAI standard: - RADIUS Support - Scalability - Roaming standard likely to be widely deployed - Must be able to accommodate at least 40 members of a roaming association each with 10 corporate customers - Efficient management of shared secret - Secure - Remote ISP must be able to determine whether a valid business relationship exists with home ISP - Robust To satisfy these requirements, he proposed the use of authentication/accounting proxy chains, in combination with hierarchical authentication routing and a new DNS record called the Authentication Route (AR) record. The use of hierarchical authentication routing is required to meet scaleability requirements in a proxy chaining scheme. If all proxies can contact each other directly the RADIUS shared secret problem becomes unmanageable quickly. The purpose of the AR record is to allow lookup of an authentication route for a given domain and to allow the determination of the appropriate destination for accounting information for a given route. The proposed format for the AR record is: Domain IN AR priority route settlement-domain There was lots of discussion about how the AR record and DNS would be used. We decided to move the discussion off to the list, since consensus was not apparent. Several formats for the NAI had been discussed on the list, including: - "Pointer to route" format fred@bigco.com fred:bigco.com - "Route" format ispa.com/bigco.com/fred ispa.com/bigco/fred It was decided to strike support of the `:' option from the document. The question arose whether we could use the DNS AR information in the Access-Request in order to pass the authentication path to the final authenticating server? Consensus was not forthcoming, so we decided to continue the discussion on the mailing list. There seems to be a preference in the group for the "pointer to route" format. A straw poll was taken and there did not seem to be rough consensus to completely remove support for the "route" format syntax. There was, however, consensus to remove support for fixed route semantics in the NAI. Since this appears to leave the route format in limbo, we decided to continue the discussion on the list. Phone Books It was suggested that we look into using Vcard and MIME to distribute phone books. Bill Simpson opined that this issue was already raised and died in the PPP WG 4 years ago and it is not a problem which can be solved. Despite this, there seems to be consensus that there is interest in the subject among WG members (at least those in attendance). A straw poll was taken and a unanimous decision made to remove scripts from the requirements document. Take to the list: Should we support Service-Type=Login-User (as defined in RFC 2058) in the roaming requirements secification? Document Status draft-ietf-roamops-imprev-00.txt It was brought up that the spec is incomplete. Merit will ask IBM Global Network (IGN) to submit a description of their implementation, or at least review the document. The Chair noted that it would be practically impossible to ensure that all implementations would be included in the document, since some people might not be willing to provide a description. If someone wants to document their implementation, they can send mail to Bernard Aboba (Editor of the document) or either of the Chairs. draft-ietf-roamops-roamreq-00.txt We decided to add the city of access to the authentication record. Miscellaneous A point was raised that PAP was deprecated by the IESG last summer. Therefore, the editor MUST remove references to PAP from draft-ietf-roamops-roamreq-00.txt.