home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / roamops / roamops-minutes-96dec.txt < prev    next >
Text File  |  1997-01-30  |  6KB  |  155 lines
  1. Editor's note:  These minutes have not been edited.
  2.  
  3. ROAMOPS WG Minutes
  4. 37th IETF, San Jose
  5.  
  6. Reported by Glen Zorn (Microsoft) from notes by Pat Calhoun (US Robotics).
  7.  
  8. The original agenda included the following items:
  9.  
  10.     Agenda bashing
  11.     Certificates vs. Proxy Chaining
  12.     NAI Formats
  13.     Phone books
  14.     What's next?
  15.  
  16. During the agenda bashing period, the following items were
  17. added to the agenda:
  18.  
  19.     Accounting
  20.     Document Status
  21.     Mobile IP Support?
  22.     PAP/CHAP as stated in draft-ietf-roamops-roamreq-00.txt
  23.     Distributed Authorization
  24.     Phone Book and Scripts
  25.  
  26. The chairs requested that agenda suggestions be made in advance
  27. for future meetings.
  28.  
  29. Bernard Aboba gave a couple of presentations
  30. on the Network Authentication Identifier (NAI) and the use of
  31. public-key certificates versus chaining proxies for inter-ISP
  32. authentication.
  33.  
  34.  
  35. Proxy Chaining vs. Public-key Certificates
  36.  
  37. Proxy chaining has the advantage of being supported by the
  38. RADIUS protocol as it exists today, but does not provide for the
  39. non-repudiation of either authentication or accounting, requires
  40. manual maintenance of configuration files and/or authentication
  41. routing and may not work over multi-hop chains due to excessive
  42. timeouts.
  43.  
  44. Certificates provide for non-repudiation of both authentication
  45. and accounting; allow automated maintenance of roaming organizations
  46. (joining, revoking membership); do not require an authentication
  47. routing scheme (any member can contact any other member without
  48. needing a shared secret).  On the other hand, the use of public-key
  49. certificates would require modification to RADIUS (or at least to
  50. RADIUS proxies), and there is some question whether RADIUS could
  51. be used to transfer certificates , given its limit on attribute size.
  52. No existing RADIUS proxies support the use of certificates.  In
  53. addition, certificates still require verification of a chain of trust
  54. and incur considerable processing overhead.
  55.  
  56. The question was raised whether IPSEC should be used as the security
  57. mechanism inter-ISP instead of what RADIUS currently uses.  If so,
  58. the overhead could cause a scalability problem, and PAP would not
  59. work with IPSEC. After some discussion, the group decided to take
  60. the issue to the mailing list.
  61.  
  62.  
  63. Network Authentication Identifier
  64.  
  65. Bernard Aboba proposed the following requirements for an NAI standard:
  66.  
  67.     - RADIUS Support
  68.     - Scalability
  69.     - Roaming standard likely to be widely deployed
  70.     - Must be able to accommodate at least 40 members of a
  71.       roaming association each with 10 corporate customers
  72.     - Efficient management of shared secret
  73.     - Secure
  74.     - Remote ISP must be able to determine whether a valid
  75.       business relationship exists with home ISP
  76.      - Robust
  77.  
  78. To satisfy these requirements, he proposed the use of
  79. authentication/accounting proxy chains, in combination with
  80. hierarchical authentication routing and a new DNS record called the
  81. Authentication Route (AR) record.  The use of hierarchical
  82. authentication routing is required to meet scaleability requirements
  83. in a proxy chaining scheme. If all proxies can contact each other
  84. directly the RADIUS shared secret problem becomes unmanageable
  85. quickly.  The purpose of the AR record is to allow lookup of an
  86. authentication route for a given domain and to allow the determination
  87. of the appropriate destination for accounting information for a given
  88. route.  The proposed format for the AR record is:
  89.  
  90.     Domain IN AR priority route settlement-domain
  91.  
  92. There was lots of discussion about how the AR record and DNS would be
  93. used. We decided to move the discussion off to the list, since consensus
  94. was not apparent.
  95.  
  96. Several formats for the NAI had been discussed on the list, including:
  97.  
  98.     - "Pointer to route" format
  99.         fred@bigco.com
  100.                 fred:bigco.com
  101.     - "Route" format
  102.                 ispa.com/bigco.com/fred
  103.                 ispa.com/bigco/fred
  104.  
  105. It was decided to strike support of the `:' option from the document.
  106. The question arose whether we could use the DNS AR information in the
  107. Access-Request in order to pass the authentication path to the final
  108. authenticating server? Consensus was not forthcoming, so we decided to
  109. continue the discussion on the mailing list. There seems to be a
  110. preference in the group for the "pointer to route" format. A straw poll
  111. was taken and there did not seem to be rough consensus to completely
  112. remove support for the "route" format syntax.  There was, however,
  113. consensus to remove support for fixed route semantics in the NAI.  Since
  114. this appears to leave the route format in limbo, we decided to continue
  115. the discussion on the list.
  116.  
  117.  
  118. Phone Books
  119.  
  120. It was suggested that we look into using Vcard and MIME to distribute
  121. phone books.  Bill Simpson opined that this issue was already raised
  122. and died in the PPP WG 4 years ago and it is not a problem which can
  123. be solved.  Despite this, there seems to be consensus that there is
  124. interest in the subject among WG members (at least those in attendance).
  125. A straw poll was taken and a unanimous decision made to remove scripts
  126. from the requirements document.  Take to the list: Should we support
  127. Service-Type=Login-User (as defined in RFC 2058) in the roaming
  128. requirements secification?
  129.  
  130.  
  131. Document Status
  132.  
  133. draft-ietf-roamops-imprev-00.txt
  134.  
  135. It was brought up that the spec is incomplete.  Merit will ask IBM
  136. Global Network (IGN) to submit a description of their implementation,
  137. or at least review the document.  The Chair noted that it would be
  138. practically impossible to ensure that all implementations would be
  139. included in the document, since some people might not be willing to
  140. provide a description.  If someone wants to document their
  141. implementation, they can send mail to Bernard Aboba (Editor of the
  142. document) or either of the Chairs.
  143.  
  144. draft-ietf-roamops-roamreq-00.txt
  145.  
  146. We decided to add the city of access to the authentication record.
  147.  
  148.  
  149. Miscellaneous
  150.  
  151. A point was raised that PAP was deprecated by the IESG last summer.
  152. Therefore, the editor MUST remove references to PAP from
  153. draft-ietf-roamops-roamreq-00.txt.
  154.  
  155.