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.