ROAMOPS Working Group                                    Bernard Aboba
     INTERNET-DRAFT                                   Microsoft Corporation
     <draft-ietf-roamops-auth-00.txt >
     26 March 1997
     
     
            The Authentication and Authorization Problem in Roaming
     
     
     1.  Status of this Memo
     
     This document is an Internet-Draft.  Internet-Drafts are working docu-
     ments of the Internet Engineering Task Force (IETF),  its  areas,  and
     its  working groups.  Note that other groups may also distribute work-
     ing documents as Internet-Drafts.
     
     Internet-Drafts are draft documents valid for a maximum of six  months
     and  may  be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as  reference  mate-
     rial or to cite them other than as ``work in progress.''
     
     To  learn  the  current status of any Internet-Draft, please check the
     ``1id-abstracts.txt'' listing contained in the Internet-Drafts  Shadow
     Directories   on   ds.internic.net   (US  East  Coast),  nic.nordu.net
     (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
     
     The  distribution  of  this memo is unlimited.  It is filed as <draft-
     ietf-roamops-auth-00.txt>, and  expires October 1, 1997.  Please  send
     comments to the authors.
     
     
     2.  Abstract
     
     This  document describes the authentication and authorization problems
     that arise in the provisioning of dialup roaming  capabilities.  These
     include issues relating to authentication routing as well as non-repu-
     diation of Access-Accepts.
     
     
     3.  Introduction
     
     As detailed in [2], solution of the authentication  and  authorization
     problem in roaming requires several elements to be put in place:
     
        1.   A  method  must  be  provided for authentications to be routed
        between the local ISP and the home authentication server. If RADIUS
        as  described  in [3] is used for authentication, then hierarchical
        authentication routing must be used in order to provide for  scala-
        bility, as described below.
     
        2.   A  mechanism  must  be  put in place to allow local ISP RADIUS
        proxies to edit authorization  attributes  so  as  to  allow  these
        attributes to relate to the local network.
     
     
     
     
     Aboba                                                         [Page 1]


     INTERNET-DRAFT                                           26 March 1997
     
     
        3.   A  mechanisms  must  be  employed to deter fraud and allow for
        auditing. Such mechanisms may include non-repudiation  for  Access-
        Accepts.
     
     This  document describes a proposed architecture for roaming authenti-
     cation and authorization. Issues relevant to hierarchical  authentica-
     tion routing and non-repudiation are discussed.
     
     
     3.1.  Terminology
     
     This document frequently uses the following terms:
     
     Network Access Server
               The  Network  Access Server (NAS) is the device that clients
               contact in order to get access to the network.
     
     RADIUS server
               This is a server which  provides  for  authentication/autho-
               rization via the protocol described in [3], and for account-
               ing as described in [4].
     
     RADIUS proxy
               In order to provide for the routing of RADIUS authentication
               and  accounting requests, a RADIUS proxy can be employed. To
               the NAS, the RADIUS proxy appears to act as a RADIUS server,
               and  to  the  RADIUS  server,  the proxy appears to act as a
               RADIUS client.
     
     Network Access Identifier
               In order to provide for the routing of RADIUS authentication
               and accounting requests, the userID field used in PPP (known
               as the Network Access Identifier or NAI) and in  the  subse-
               quent  RADIUS  authentication  and  accounting requests, can
               contain structure. This structure provides a means by  which
               the  RADIUS  proxy  will locate the RADIUS server that is to
               receive the request.
     
     Roaming relationships
               Roaming relationships include relationships  between  compa-
               nies  and ISPs, relationships among peer ISPs within a roam-
               ing association, and relationships  between  an  ISP  and  a
               roaming  consortia. Together, the set of relationships form-
               ing a path between a local ISP's  authentication  proxy  and
               the home authentication server is known as the roaming rela-
               tionship path.
     
     
     4.  Overview of the roaming authentication and authorization architec-
     ture
     
     The  goal of the roaming authentication and authorization architecture
     is to enable roaming users to be  authenticated  and  authorized  when
     dialing phone numbers belonging to ISPs other than their home ISP. The
     
     
     
     Aboba                                                         [Page 2]


     INTERNET-DRAFT                                           26 March 1997
     
     
     authentication and authorization architecture, which is  shown  below,
     involves  interactions  between  network  devices  such  as  NASes and
     routers, authentication proxies, and authentication servers.
     
     In this architecture, authentication proxies are used to relay authen-
     tication  requests  from  the  local  ISP  to  the home authentication
     server. While the local ISP authentication proxy may  edit  authoriza-
     tion  attributes  returned by the home authentication server, so as to
     make them compatible with the local network, intermediate proxies MUST
     NOT  edit  the attribute set passed to it by another proxy or the home
     authentication server. This is necessary in order to ensure that crit-
     ical  attributes  relating  to  security (such as tunnel attributes or
     EAP-Message attributes) are not modified along the way.
     
     In the discussion that follows, we assume that  BIGCO  has  contracted
     with ISPA to provide roaming services. In turn ISPA has joined a roam-
     ing consortia ISPGROUP. User Fred then travels to another part of  the
     world  and  dials  into  a  NAS  device operated by ISPB, who has also
     joined roaming consortia ISPGROUP. Fred attempts  to  authenticate  to
     the  NAS  device  as  fred@bigco.com,  using  the  PPP protocol and an
     authentication protocol such as PAP, CHAP, or EAP.
     
          +------------+      +------------+          +------------+
          |            |      |            |          |            |
          |    ISPB    |      |  BIGCO     |          |    ISPA    |
          |   Router   |      |  RADIUS    |<---------|   RADIUS   |
          |            |      |  Server    |          |   Proxy    |
          |            |      |            |          |            |
          +------------+      +------------+          +------------+
                |                                            ^
                |                                            |
     RADIUS     |                                            |
     Protocol   |                     Inter-organizational   |
                |                     Authentication Events  |
                |                                            |
                |                                            |
                V                                            V
          +------------+                               +------------+
          |            |                               |            |
          |    ISPB    |      Inter-organizational     |  ISPGROUP  |
          |   RADIUS   |<----------------------------->|   RADIUS   |
          |    Proxy   |\    Authentication Events     |  Proxy     |
          |            | \                             |            |
          |            |  \                            |            |
          +------------+   \                           +------------+
                ^           \
                |            \ Intra-organizational
     RADIUS     |             \   Authentication Events
     Protocol   |              \
                |               \
                |                \
                |                 \
                |                  \
          +------------+      +------------+
     
     
     
     Aboba                                                         [Page 3]


     INTERNET-DRAFT                                           26 March 1997
     
     
          |            |      |            |
          |     ISPB   |      |    ISPB    |
          |     NAS    |      |    RADIUS  |
          |            |      |    Server  |
          |            |      |            |
          +------------+      +------------+
                ^
                |
     PPP        |
     Protocol   |
                |
                V
          +------------+
          |            |
          |            |
          |    Fred    |
          |            |
          |            |
          +------------+
     
     
     5.  Authentication and authorization recommendations
     
     In order to authenticate roaming users, it is necessary to be able  to
     route  the authentication requests from the NAS of the remote ISP to a
     server maintained by the home ISP. How the  authentication  is  routed
     depends  on  the security mechanisms employed by the protocols used to
     communicate between the NAS and the home ISP's authentication  server,
     as well the roaming relationships established between the parties.
     
     
     5.1.  Hierarchical authentication routing and RADIUS
     
     Use  of  proxy  RADIUS and hierarchical authentication routing is pro-
     posed for use in situations where the members of the roaming consortia
     desire  to use RADIUS as described in [3] as their authentication pro-
     tocol.  In these cirumstances, authentication traffic will be  secured
     via  shared  secrets,  and hierarchical authentication routing must be
     employed to enhance scalability.  In  order  to  support  hierarchical
     authentication  routing, it is recommended that a Roaming Relationship
     (REL) record be added to the DNS, as described in [8].
     
     Note that direct contact between the local NAS  and  the  home  RADIUS
     server  is not necessarily desirable, regardless of whether public key
     authentication technology is available.  Direct  contact  between  the
     local  NAS  and the home RADIUS server has the potential to exacerbate
     interoperability problems since it implies, for example, that the  two
     end  systems must be running the same accounting protocol and that the
     home  ISP's  RADIUS  server  must  be  able  to  return  configuration
     attributes that the remote NAS understands. Thus  authentication prox-
     ies are useful for more than just authentication routing.
     
     
     
     
     
     
     Aboba                                                         [Page 4]


     INTERNET-DRAFT                                           26 March 1997
     
     
     5.2.  Use of RADIUS over IPSEC
     
     In situations where members of the roaming consortia are able to  sup-
     port  public  key  authentication  as  well as DNS Security, IPSEC and
     ISAKMP, it is recommended that the  working  group  consider  optional
     support for RADIUS running over IPSEC. Where RADIUS is run over IPSEC,
     the RADIUS authenticator field will not be utilized, and the Signature
     attribute  will not be processed. Where RADIUS over IPSEC is used, the
     local ISP's RADIUS proxy may be able to contact the  home  ISP  server
     directly,  and  negotiate  a session key without the need for a shared
     secret.
     
     However, in order for direct contact to be feasible between the  local
     ISP  proxy and the home authentication server, the home authentication
     server must be prepared to return its roaming credentials to the local
     ISP  proxy.  This  is  required in order for the local ISP proxy to be
     able to verify the roaming relationship path. As a result, it will not
     be  necessary for the authentication to traverse this path in order to
     verify it.
     
     Roaming credentials consist of a series of tokens  testifying  to  the
     validity of the roaming relationship path stretching between the local
     ISP and the home authentication server. For example, if BIGCO has del-
     egated  roaming  authority  to ISPA, then its roaming credentials will
     include a token signed by ISPA testifying to the validity of the roam-
     ing  relationship  between  BIGCO and ISPA. The tokens returned by the
     home authentication server would include the following:
     {PK_BIGCO, Expiration date}^SK_ISPA
     {PK_ISPA, Expiration date}^SK_ISPGROUP1
     
     
     5.3.  Non-repudiation of Access-Accepts
     
     In situations where members of the roaming consortia are able to  sup-
     port  public  key  authentication, it may be desirable to support non-
     repudiation of Access-Accepts as an optional capability. This capabil-
     ity  is  supported via inclusion of a token by the home authentication
     server within the Access-Accept. This  token  consists  of  a  message
     digest,  signed  by the home authentication server. The message digest
     is computed over the Access-Accept, with the portions  of  the  packet
     which may be acceptably modified (such as the authenticator field) set
     to zero. In order to proof of a user login, it has been suggested that
     the  signature  also  be applied to a transcript of the authentication
     conversation between the NAS and the authenticating peer.
     
     Please note that support for non-repudiation in Access-Accepts is only
     valuable  as  an integrity-checking mechanism when the local ISP proxy
     cannot contact the home authentication server directly, and thus there
     is  concern  over  modification  of  the Access-Accept by intermediate
     proxies. However, in addition, it may be desirable to include the non-
     repudiation  token  with the accounting record in order to demonstrate
     its authenticity.
     
     
     
     
     
     Aboba                                                         [Page 5]


     INTERNET-DRAFT                                           26 March 1997
     
     
     6.  Hierarchical authentication routing architecture
     
     
     
     6.1.  Justification for hierarchical authentication routing
     
     Since the RADIUS protocol is commonly implemented both by NAS  vendors
     as  well  as by ISPs, RADIUS is today commonly used as a mechanism for
     roaming authentication and authorization.
     
     Although the choice of RADIUS is expedient, it has  significant  draw-
     backs.   In particular, routing of RADIUS authentication/authorization
     messages is complicated by the security  architecture  of  the  RADIUS
     protocol.  The  RADIUS  protocol  requires the maintenance of a shared
     secret between the NAS and the RADIUS server or proxy. Therefore, were
     RADIUS authentication requests to be routed directly, the result would
     be a requirement for maintenance of shared secrets between  every  NAS
     device  and  every  RADIUS  server.  This  would  get out of hand very
     quickly.  As  a  result,  hierarchical  authentication  routing  is  a
     requirement for scalable authentication of roaming users via RADIUS.
     
     Authentication  routes can be maintained either in proxy configuration
     files or via DNS as described in [8].  Note that even if DNS is  used,
     configuration files are still necessary in cases where proxy RADIUS is
     employed, since they provide the RADIUS proxy with the list of  shared
     secrets.  This  list of shared secrets is also a list of systems whose
     owners have a Roaming relationship with the configuring ISP.
     
     Hierarchical authentication routing is implemented  via  a  multi-tier
     RADIUS  proxy system. This allows ISPs to maintain shared secrets only
     with the roaming consortia itself or other consortium members, as well
     as with customers who have delegated roaming responsibilities to them.
     
     For example, let us assume that we have n members of a roaming consor-
     tia,  each of which have m distinct corporate customers whom they wish
     to provide access for.  These corporate  customers  wish  to  maintain
     their  own  RADIUS servers so as to be able to manage their users more
     efficiently. Thus we have n * m corporate entities that wish to  allow
     their  users  to  have access to the facilities of the roaming consor-
     tium.
     
     If the RADIUS proxy of a given ISP were to contact each RADIUS  server
     directly,  each  RADIUS  proxy  would  need  to maintain n * m + n - 1
     shared proxy secrets. This is  a  shared  secret  for  each  corporate
     entity,  plus  a  shared secret for each member of the roaming consor-
     tium. For the case of 500 roaming consortia  members,  each  with  500
     corporate customers, this translates to 250499 shared secrets per ISP.
     This would be unmanageable.
     
     On the other hand,  let  us  assume  that  we  implement  hierarchical
     authentication  routing. In this case, the RADIUS proxy of a given ISP
     would only need to contact the RADIUS proxies of  the  other  ISPs  in
     ISPGROUP as well as the RADIUS servers of its own corporate customers.
     To do this, it would only need to maintain n-1+m shared  secrets.  For
     
     
     
     Aboba                                                         [Page 6]


     INTERNET-DRAFT                                           26 March 1997
     
     
     the  case  of  500  roaming consortia members, each with 500 corporate
     customers, this translates to 999 shared secrets per ISP,  a  dramatic
     reduction.
     
     If the RADIUS proxies of each ISP contact a consortium proxy, the num-
     ber of shared secrets is further reduced. In this case, a given  proxy
     needs to maintain m+1 shared secrets, while the consortium proxy needs
     to maintain n shared secrets, one for each consortium member.
     
     
     6.2.  Details of hierarchical authentication routing
     
     As described in [8], Roaming Relationship (REL) RRs  in  the  DNS  are
     used  in order to construct the roaming relationship path. Please note
     that while DNS Security may  be  used  to  verify  the  integrity  and
     authenticity of the REL RRs, it does not vouch for the validity of the
     roaming relationships themselves. As a result, where it is not  possi-
     ble  for the local ISP proxy to contact the home authentication server
     directly and retrieve roaming credentials, it  is  necessary  for  the
     local  ISP  to  route the authentication over the roaming relationship
     path in order to verify it.
     
     As a result, in cases where  hierarchical  authentication  routing  is
     required,  the roaming relationship path is used as the authentication
     route. The route is typically constructed  by  the  local  ISP  proxy,
     which  includes  it within the Authentication-Route attribute included
     in the RADIUS Access-Request. In order to ensure that  the  accounting
     agent, who will subsequently receive an accounting record has also had
     the opportunity to vouchsafe for the validity of the roaming relation-
     ship path, the accounting agent is typically included as the first hop
     in the roaming relationship path.
     
     In order to construct the roaming relationship  path,  the  local  ISP
     proxy  begins  by  checking  whether the home authentication domain is
     listed in its configuration files as an accounting agent. If so,  then
     the  authentication  request (and the subsequent accounting record) is
     routed to the home authentication server directly; if  not,  then  the
     local  ISP  queries  for the REL RR of the home authentication domain.
     Typically such a query will return one or more ISPs or roaming consor-
     tia  to  whom  the  home  authentication  domain has delegated roaming
     authority. Once again, the local ISP proxy checks whether one of these
     domains is listed within its configuration files as a valid accounting
     agent. If so, then it routes the authentication (and subsequently  the
     accounting  record)  to  the accounting agent. If not, then it queries
     the DNS for the REL RRs for these ISPs and/or roaming  consortia.  The
     process typically results in a roaming relationship path within a max-
     imum of two hops.
     
     Once the roaming relationship path has been constructed by  the  local
     ISP,  it  is  included in an Authentication-Route attribute within the
     Access-Request. Intermediate proxies MUST forward  the  authentication
     along the requested Authentication-Route if it is possible to do so.
     
     
     
     
     
     Aboba                                                         [Page 7]


     INTERNET-DRAFT                                           26 March 1997
     
     
     7.  Proposed RADIUS attributes for roaming
     
     
     
     7.1.  Authentication-Route
     
     Description
     
        This attribute allows an authentication route to be included within
        a RADIUS Access-Request or Access-Reply sent between  RADIUS  prox-
        ies.  RADIUS  proxies  receiving  a message with an Authentication-
        Route attribute MUST honor the attribute if it is  possible  to  do
        so.
     
        A  summary  of  the  Authentication-Route attribute format is shown
        below.  The fields are transmitted from left to right.
     
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |      Type     |    Length     |           String              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |      String...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        Type
     
           73 for Authentication-Route
     
        Length
     
           >=3
     
        String
     
           The String field includes the  authentication  route,  which  is
           represented  as a series of domains separated by /. For example,
           a    valid     authentication     route     is     ispb.com/isp-
           group.com/ispa.com/bigco.com/
     
     
     7.2.  Authentication-Token
     
     Description
     
        This  attribute allows an authentication server to include a signed
        token within a RADIUS Access-Accept, in order to provide  for  non-
        repudiation.
     
        A  summary  of  the  Authentication-Token attribute format is shown
        below.  The fields are transmitted from left to right.
     
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
     
     
     
     Aboba                                                         [Page 8]


     INTERNET-DRAFT                                           26 March 1997
     
     
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |      Type     |    Length     |           String              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |      String...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        Type
     
           74 for Authentication-Token
     
        Length
     
           ?
     
        String
     
           The String field includes the authentication token.
     
     
     7.3.  Roaming-Credentials
     
     Description
     
        This attribute allows a home authentication server to  include  its
        roaming  credentials  within  a RADIUS Access-Accept, thus enabling
        direct contact between the local ISP proxy and the home authentica-
        tion  server.  More  than  one Roaming-Credentials attribute may be
        included within an  Access-Accept,  in  order  to  allow  the  home
        authentication server to present sufficient credentials to validate
        the roaming relationship path between itself and the local ISP.
     
        A summary of the  Roaming-Credentials  attribute  format  is  shown
        below.  The fields are transmitted from left to right.
     
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |      Type     |    Length     |           String              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |      String...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
        Type
     
           75 for Roaming-Credentials
     
        Length
     
           ?
     
        String
     
           The String field includes the roaming credentials, which consist
           of tokens with the following structure:
     
     
     
     Aboba                                                         [Page 9]


     INTERNET-DRAFT                                           26 March 1997
     
     
           {PK_DelegatingEntity, Expiration date}^SK_SigningEntity
     
     
     8.  Security Concerns
     
     
     
     8.1.  Attacks on the DNS servers
     
     In the absence of DNS security, an attacker were to  gain  control  of
     the DNS server hosting the BIGCO zone files, they could change the REL
     and  SRV  records  to  route  roaming  authentication  and  accounting
     requests to bogus servers.
     
     However, since RADIUS is secured by a shared secret, this attack would
     not result in more than a denial of service, as long as  the  attacker
     did  not  also  obtain  the shared secrets which would allow the bogus
     RADIUS server's Access-Reply message to be accepted. This is why it is
     important that roaming relationship paths be verified either via roam-
     ing credentials or via hierarchical authenticaton routing.
     
     
     8.2.  Attacks against RADIUS proxies
     
     Without non-repudiation of Access-Accepts, it is possible that a prox-
     ied authentication may be modified in transit between the home authen-
     tication server and the local ISP proxy. Thus, it is  possible  for  a
     compromised RADIUS proxy to modify security attributes returned by the
     home ISP, or even to change a NAK to an ACK.
     
     Without non-repudiation, it is also not  possible  for  an  accounting
     agent  to confirm that the home ISP authentication server authorized a
     session. This may present problems if a dispute should arise over  the
     home ISP's roaming charges.
     
     Note  that even with public key authentication facilities, there is no
     guarantee  that  the  local  ISP  proxy  will  not   modify   security
     attributes.   In  order to guarantee that the authorization attributes
     will be compatible with the local network, the local  ISP  proxy  will
     typically edit the authorization attributes returned by the home ISP's
     authentication server.
     
     
     
     9.  Acknowledgments
     
     Thanks to Glen Zorn of Microsoft and Pat Calhoun  of  USR  for  useful
     discussions of this problem space.
     
     
     10.  References
     
     [1]  B. Aboba, J. Lu, J. Alsop, J. Ding.  "Review of Roaming Implemen-
     tations." draft-ietf-roamops-imprev-01.txt, Microsoft, Aimnet,  i-Pass
     
     
     
     Aboba                                                        [Page 10]


     INTERNET-DRAFT                                           26 March 1997
     
     
     Alliance, Asiainfo, January, 1997.
     
     [2]   B.  Aboba, G. Zorn.  "Dialing Roaming Requirements." draft-ietf-
     roamops-roamreq-03.txt, Microsoft, March, 1997.
     
     [3]  C. Rigney, A. Rubens, W. Simpson, S. Willens.  "Remote  Authenti-
     cation  Dial  In  User Service (RADIUS)." RFC 2058, Livingston, Merit,
     Daydreamer, January, 1997.
     
     [4]  C. Rigney.  "RADIUS Accounting." RFC 2059,  Livingston,  January,
     1997.
     
     [5]  R.  Fielding,  et  al.  "Hypertext Transfer Protocol - HTTP/1.1."
     draft-ietf-http-v11-spec-07, UC Irvine, August, 1996.
     
     [6] A. Gulbrandsen, P. Vixie.  "A DNS RR for specifying  the  location
     of  services  (DNS  SRV)."  RFC 2052, Troll Technologies, Vixie Enter-
     prises, October 1996.
     
     [7] D. Eastlake, 3rd, C. W. Kaufman.   "Domain  Name  System  Security
     Extensions." Draft-ietf-dnnsec-secext-10.txt, CyberCash, Iris, August,
     1996.
     
     [8] B. Aboba. "The Roaming Relationships  (REL) Record in the  DNS.  "
     draft-ietf-roamops-dnsrr-03.txt, Microsoft, March, 1997.
     
     [9]  C.  Rigney,  W. Willats.  "RADIUS Extensions." draft-ietf-radius-
     ext-00.txt, Livingston, January, 1997.
     
     [10] R. Rivest, S. Dusse.  "The  MD5  Message-Digest  Algorithm",  RFC
     1321,  MIT  Laboratory  for  Computer Science, RSA Data Security Inc.,
     April 1992.
     
     [11] S. Bradner.  "Key words for use in RFCs to  Indicate  Requirement
     Levels."  draft-bradner-key-words-02.txt,  Harvard University, August,
     1996.
     
     [12] B. Aboba.  "The Network  Access  Identifier  (NAI)."  draft-ietf-
     roamops-nai-02.txt, Microsoft, March, 1997.
     
     
     11.  Authors' Addresses
     
     Bernard Aboba
     Microsoft Corporation
     One Microsoft Way
     Redmond, WA 98052
     
     Phone: 206-936-6605
     EMail: bernarda@microsoft.com
     
     
     
     
     
     
     
     Aboba                                                        [Page 11]