[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05                                             
     RADIUS Working Group                                       Pat Calhoun
     INTERNET-DRAFT                                US Robotics Access Corp.
     <draft-ietf-radius-eap-00.txt>                         Allan C. Rubens
     19 February 1997                                   Merit Network, Inc.
                                                              Bernard Aboba
                                                                  Microsoft
     
     
              Extensible Authentication Protocol Support in RADIUS
     
     
     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-radius-eap-00.txt>, and  expires September 1, 1997.  Please  send
     comments to the authors.
     
     
     2.  Abstract
     
     The  Extensible  Authentication Protocol (EAP) is a PPP extension that
     provides support for additional  authentication  methods  within  PPP.
     This  document  describes how the EAP-Message and Signature attributes
     may be used for providing EAP support within RADIUS.
     
     
     3.  Introduction
     
     The Extensible Authentication Protocol (EAP), described in  [1],  pro-
     vides  a  standard  mechanism for support of additional authentication
     methods within PPP.  Through the use of EAP, support for a  number  of
     authentication  schemes may be added, including token cards, Kerberos,
     Public Key, S/Key, and others.  In order to provide for support of EAP
     within  RADIUS,  two  new  attributes, EAP-Message and Signature, were
     introduced as RADIUS extensions in [5]. This  document  describes  how
     these  new  attributes  may  be  used for providing EAP support within
     RADIUS.
     
     
     
     
     
     Calhoun, Rubens & Aboba                                       [Page 1]


     INTERNET-DRAFT                                        19 February 1997
     
     
     The scheme described here is similar to that proposed in [2], in  that
     the  RADIUS  server is used to shuttle RADIUS-encapsulated EAP Packets
     between the NAS and a backend security server. While the  conversation
     between  the RADIUS server  and the backend security server will typi-
     cally occur using a proprietary  protocol  developed  by  the  backend
     security server vendor, it is also possible to use RADIUS-encapsulated
     EAP via the EAP-Message attribute. This has the advantage of  allowing
     the  RADIUS server to support EAP without the need for authentication-
     specific code, which can instead reside on a backend security  server.
     
     
     3.1.  Requirements language
     
     This specification uses the same words as [7] for defining the signif-
     icance of each particular requirement.  These words are:
     
     
     MUST      This word, or the adjectives "REQUIRED"  or  "SHALL",  means
               that the definition is an absolute requirement of the speci-
               fication.
     
     MUST NOT  This phrase, or the phrase "SHALL NOT", means that the defi-
               nition is an absolute prohibition of the specification.
     
     SHOULD    This  word, or the adjective "RECOMMENDED", means that there
               may exist  valid  reasons  in  particular  circumstances  to
               ignore  a particular item, but the full implications must be
               understood and carefully weighed before choosing a different
               course.
     
     SHOULD NOT
               This phrase means that there may exist valid reasons in par-
               ticular  circumstances  when  the  particular  behavior   is
               acceptable  or even useful, but the full implications should
               be understood and the case carefully weighed  before  imple-
               menting any behavior described with this label.
     
     MAY       This  word,  or the adjective "OPTIONAL", means that an item
               is truly optional.  One vendor may  choose  to  include  the
               item because a particular marketplace requires it or because
               the vendor feels that it enhances the product while  another
               vendor may omit the same item.  An implementation which does
               not include a particular option MUST be prepared to interop-
               erate  with  another  implementation  which does include the
               option, though perhaps with reduced  functionality.  In  the
               same  vein an implementation which does include a particular
               option MUST be prepared to interoperate with another  imple-
               mentation  which  does  not  include  the option.(except, of
               course, for the feature the option provides)
     
     An implementation is not compliant if it fails to satisfy one or  more
     of  the must or must not requirements for the protocols it implements.
     An implementation that satisfies all the must, must  not,  should  and
     should   not   requirements   for   its   protocols   is  said  to  be
     
     
     
     Calhoun, Rubens & Aboba                                       [Page 2]


     INTERNET-DRAFT                                        19 February 1997
     
     
     "unconditionally compliant"; one that satisfies all the must and  must
     not requirements but not all the should or should not requirements for
     its protocols is said to be "conditionally compliant."
     
     
     4.  Protocol overview
     
     The EAP conversation between  the  authenticating  peer  and  the  NAS
     begins with the negotiation of EAP within LCP. Once EAP has been nego-
     tiated, the NAS will typically send to  the  RADIUS  server  a  RADIUS
     Access-Request  packet  containing an EAP-Message attribute signifying
     EAP-Start. EAP-Start is indicated by sending an EAP-Message  attribute
     with  a  length of 2 (no data). The Port number and NAS Identifier are
     included in the attributes issued by the  NAS  in  the  Access-Request
     packet.
     
     If  the  RADIUS  server  supports EAP, it MUST respond with an Access-
     Challenge packet containing an EAP-Message attribute. The  EAP-Message
     attribute  includes an encapsulated EAP packet which is then passed on
     to the authenticating peer. The Access-Challenge typically  will  con-
     tain  an  EAP-Message  attribute encapsulating an EAP-Request/Identity
     message, requesting the authenticating peer to  identify  itself.  The
     NAS  will  then respond with a RADIUS Access-Request packet containing
     an EAP-Message attribute encapsulating an EAP-Response, etc. The  con-
     versation  continues  until  either  a  RADIUS Access-Reject packet is
     received (with an  EAP-Message  attribute  encapsulating  EAP-Failure)
     which  results  in the NAS disconnecting the user, or a RADIUS Access-
     Accept packet is received (with an EAP-Message attribute encapsulating
     EAP-Success)  successfully ending the authentication phase.  Note that
     if a RADIUS Access-Reject packet with an EAP-Message attribute  encap-
     sulating  EAP-Failure  is  received  from  the  RADIUS Server, the NAS
     SHOULD issue an LCP Terminate Request to the authenticating peer.
     
     The above scenario creates a situation in which the NAS never needs to
     manipulate  an  EAP  packet.  An alternative may be used in situations
     where an EAP-Request/Identity message will always be sent by  the  NAS
     to  the authenticating peer. This involves having the NAS send an EAP-
     Request/Identity message to the authenticating  peer,  and  forwarding
     the  EAP-Response/Identity packet to the RADIUS server in the EAP-Mes-
     sage attribute of a RADIUS Access-Request packet. While this  approach
     will  save a round-trip, it cannot be universally employed.  There are
     circumstances in which the user's identity may not be needed (such  as
     when  authentication and accounting is handled based on the calling or
     called phone number), and therefore an EAP-Request/Identity packet may
     not necessarily be issued by the NAS to the authenticating peer.
     
     Unless the NAS interprets the EAP-Response/Identity packet returned by
     the authenticating peer, it will not have access to the  user's  iden-
     tity.  Therefore,  it  is  suggested that the RADIUS Server return the
     user's identity by inserting it in the User-Name attribute  of  subse-
     quent  Access-Challenge  and Access-Accept packets. Without the user's
     identity, accounting and billing becomes very difficult to manage.
     
     
     
     
     
     Calhoun, Rubens & Aboba                                       [Page 3]


     INTERNET-DRAFT                                        19 February 1997
     
     
     In cases where a backup RADIUS servers is available, were the  primary
     server  to  fail  at any time during the EAP conversation, it would be
     desirable for the NAS to be able to redirect the  conversation  to  an
     alternate  RADIUS server. However, for the backup server to be able to
     pick up the conversation, it must be provided with the  state  of  the
     EAP conversation prior to the interruption.
     
     This  can  be accomplished by having the RADIUS Access-Request include
     the series of EAP-Message attributes representing the previous history
     of  the  EAP conversation. Similarly, the RADIUS Challenge returned by
     the  RADIUS  server  must  also  include  all   previous   EAP-Message
     attributes.  The  sequence  number  field in the EAP-Message attribute
     MUST be used in order to determine which attribute is to be processed.
     The  attribute  with  the  highest  sequence number is the most recent
     attribute.
     
     The RADIUS Access-Accept/EAP-Message/EAP-Success packet  MUST  contain
     all  of  the  expected  attributes  which are currently returned in an
     Access-Accept packet.
     
     For proxied RADIUS requests there are two methods of  processing.   If
     the domain is determined based on the DNIS the RADIUS Server may proxy
     the initial RADIUS Access-Request/EAP-Start. If the domain  is  deter-
     mined  based  on  the  user's  identity,  the local RADIUS Server MUST
     respond  with  a  RADIUS  Access-Challenge/EAP-Identity  packet.   The
     response  from  the  authenticating  peer MUST be proxied to the final
     authentication server.
     
     For proxied RADIUS requests, the  NAS  may  receive  an  Access-Reject
     packet  in  response  to its Access-Request/EAP-Identity packet.  This
     would occur if the message was proxied to a RADIUS Server  which  does
     not  support  the  EAP-Message extension.  At this point, the NAS MUST
     re-open LCP with the authenticating peer and request  either  CHAP  or
     PAP  as  the  authentication  protocol.  Again,  such an Access-Reject
     packet indicating lack of EAP capability will not contain an  EAP-Mes-
     sage attribute.
     
     If  the  NAS  is unable to negotiate EAP with the authenticating peer,
     what happens next is a matter of policy. In circumstances where EAP is
     required  of  all users accessing the NAS, the NAS MUST disconnect the
     user. However, in circumstances where EAP is mandatory for some users,
     and  optional  or not required for others, the decision cannot be made
     until the user's identity is ascertained. In this case, the  NAS  will
     negotiate  another  authentication method, such as CHAP, and will pass
     the User-Name and CHAP-Password attributes to the RADIUS Server in  an
     Access-Request  packet.  If  the user is not required to use EAP, then
     the RADIUS Server will respond with an Access-Accept or  Access-Reject
     packet  as appropriate. However, should the user require EAP, then the
     RADIUS Server will respond with an Access-Challenge packet  containing
     an EAP-Message attribute. The EAP-Message attribute will either encap-
     sulate an EAP-Request/Identity packet, or if the RADIUS  Server  makes
     use  of the User-Name attribute in the Access-Request, it may encapsu-
     late an EAP challenge. On receiving the EAP-Message attribute, the NAS
     will either attempt to negotiate EAP if it had not done so previously,
     
     
     
     Calhoun, Rubens & Aboba                                       [Page 4]


     INTERNET-DRAFT                                        19 February 1997
     
     
     or if negotiation had previously been attempted and  failed,  it  MUST
     disconnect the user.
     
     The NAS is not responsible for the retransmission of any EAP messages.
     The authenticating peer and the RADIUS Server are responsible for  any
     retransmissions.
     
     The  example  below  shows the conversation between the authenticating
     peer, NAS, and RADIUS server, for the case of an S/Key authentication.
     S/Key  is  used  only  for illustrative purposes; other authentication
     protocols could also have been used, although they would show somewhat
     different behavior.
     
     
     Authenticating Peer     NAS                      RADIUS Server
     -------------------     ---                      -------------
     
                             <- PPP LCP EAP-Request
     PPP LCP EAP ACK ->
                             RADIUS
                             Access-Request/
                             EAP-Message/Start ->
                                                      <- RADIUS
                                                      Access-Challenge/
                                                      EAP-Message/Identity
                             <- PPP EAP-Request/
                             Identity
     PPP EAP-Response/
     Identity (MyID) ->
                             RADIUS
                             Access-Request/
                             EAP-Message/
                             EAP-Response/
                             (MyID) ->
                                                       <- RADIUS
                                                       Access-Challenge/
                                                       EAP-Message/EAP-Request
                                                       S-Key/S-Key Challenge
                             <- PPP EAP-Request/
                             S-Key/
                             S-Key Challenge
     PPP EAP-Response/
     S-Key, S-Keypw ->
                             RADIUS
                             Access-Request/
                             EAP-Message/
                             EAP-Response/
                             S-Key, S-Keypw ->
                                                        <- RADIUS
                                                        Access-Accept/
                                                        EAP-Message/EAP-Success
                                                        (other attributes)
                             <- PPP EAP-Success
     IPCP phase starts
     
     
     
     Calhoun, Rubens & Aboba                                       [Page 5]


     INTERNET-DRAFT                                        19 February 1997
     
     
     In  the  case  where  the  NAS  sends  the authenticating peer an EAP-
     Request/Identity packet without first sending an EAP-Start  packet  to
     the RADIUS server,  the conversation would appear as follows:
     
     Authenticating Peer     NAS                      RADIUS Server
     -------------------     ---                      -------------
     
                             <- PPP LCP EAP-Request
     PPP LCP EAP ACK ->
                             <- PPP EAP-Request/
                             Identity
     PPP EAP-Response/
     Identity (MyID) ->
                             RADIUS
                             Access-Request/
                             EAP-Message/
                             EAP-Response/
                             (MyID) ->
                                                       <- RADIUS
                                                       Access-Challenge/
                                                       EAP-Message/EAP-Request
                                                       S-Key/S-Key Challenge
                             <- PPP EAP-Request/
                             S-Key/
                             S-Key Challenge
     PPP EAP-Response/
     S-Key, S-Keypw ->
                             RADIUS
                             Access-Request/
                             EAP-Message/
                             EAP-Response/
                             S-Key, S-Keypw ->
                                                        <- RADIUS
                                                        Access-Accept/
                                                        EAP-Message/EAP-Success
                                                        (other attributes)
                             <- PPP EAP-Success
     IPCP phase starts
     
     In  the  case where the client fails EAP authentication, the conversa-
     tion would appear as follows:
     
     Authenticating Peer     NAS                      RADIUS Server
     -------------------     ---                      -------------
     
                             <- PPP LCP EAP-Request
     PPP LCP EAP ACK ->
     RADIUS
                             Access-Request/
                             EAP-Message/Start ->
                                                      <- RADIUS
                                                      Access-Challenge/
                                                      EAP-Message/Identity
                             <- PPP EAP-Request/
     
     
     
     Calhoun, Rubens & Aboba                                       [Page 6]


     INTERNET-DRAFT                                        19 February 1997
     
     
                             Identity
     PPP EAP-Response/
     Identity (MyID) ->
                             RADIUS
                             Access-Request/
                             EAP-Message/
                             EAP-Response/
                             (MyID) ->
                                                       <- RADIUS
                                                       Access-Challenge/
                                                       EAP-Message/EAP-Request
                                                       S-Key/S-Key Challenge
                             <- PPP EAP-Request/
                             S-Key/
                             S-Key Challenge
     PPP EAP-Response/
     S-Key, S-Keypw ->
                             RADIUS
                             Access-Request/
                             EAP-Message/
                             EAP-Response/
                             S-Key, S-Keypw ->
                                                        <- RADIUS
                                                        Access-Reject/
                                                        EAP-Message/EAP-Failure
                             <- PPP EAP-Failure
                             (client disconnected)
     
     In the case that the RADIUS server or proxy does not support  EAP-Mes-
     sage, the conversation would appear as follows:
     
     Authenticating Peer     NAS                         RADIUS Server
     -------------------     ---                         -------------
     
                             <- PPP LCP EAP-Request
     PPP LCP EAP ACK ->
                             RADIUS
                             Access-Request/
                             EAP-Message/Start ->
                                                         <- RADIUS
                                                         Access-Reject
                             <- PPP LCP
                             CHAP-Request
     PPP LCP
     CHAP-Response->
                             RADIUS
                             Access-Request->
                                                         <- RADIUS
                                                         Access-Accept
     
     In  the  case  where the local RADIUS Server does support EAP-Message,
     but the remote RADIUS Server does not, the conversation  would  appear
     as follows:
     
     
     
     
     Calhoun, Rubens & Aboba                                       [Page 7]


     INTERNET-DRAFT                                        19 February 1997
     
     
     Authenticating Peer     NAS                         RADIUS Server
     -------------------     ---                         -------------
     
                             <- PPP LCP EAP-Request
     PPP LCP EAP ACK ->
                             RADIUS
                             Access-Request/
                             EAP-Message/Start ->
                                                         <- RADIUS
                                                         Access-Challenge/
                                                         EAP-Message/Identity
                             <- PPP EAP-Request/
                             Identity
     PPP EAP-Response/
     Identity
     (MyID) ->
                             RADIUS
                             Access-Request/
                             EAP-Message/EAP-Response/
                             (MyID) ->
                                                         <- RADIUS
                                                         Access-Reject
                                                         (proxied from remote
                                                         RADIUS Server)
                             <- PPP LCP
                             CHAP-Request
     PPP LCP
     CHAP-Response->
                             RADIUS
                             Access-Request->
                                                         <- RADIUS
                                                         Access-Accept
                                                         (proxied from remote
                                                         RADIUS Server)
     
     In  the  case  where the authenticating peer does not support EAP, but
     where EAP is required for that user, the conversation would appear  as
     follows:
     
     Authenticating Peer     NAS                         RADIUS Server
     -------------------     ---                         -------------
     
                             <- PPP LCP EAP-Request
     PPP LCP EAP NACK ->
                             <- PPP LCP CHAP-Request
     PPP LCP
     CHAP-Response ->
                             RADIUS
                             Access-Request/
                             User-Name,
                             CHAP-Password ->
                                                         <- RADIUS
                                                         Access-Challenge/
                                                         EAP-Message
     
     
     
     Calhoun, Rubens & Aboba                                       [Page 8]


     INTERNET-DRAFT                                        19 February 1997
     
     
                             (User Disconnected)
     
     
     5.  Alternative uses
     
     While  the  conversation  between  the  RADIUS server  and the backend
     security server will typically  occur  using  a  proprietary  protocol
     developed  by  the backend security server vendor, it is also possible
     to use RADIUS-encapsulated  EAP  via  the  EAP-Message  and  Signature
     attributes.  This  has  the advantage of allowing the RADIUS server to
     support EAP without the need for authentication-specific  code  within
     the  RADIUS  server. Authentication-specific code can then reside on a
     backend security server instead.
     
     In the case where RADIUS-encapsulated EAP is used  in  a  conversation
     between  a  RADIUS  server and a backend security server, the Security
     Server will  typically  return  an  Access-Accept/EAP-Success  message
     without  inclusion of the expected attributes currently returned in an
     Access-Accept. This means that the RADIUS  server  will  need  to  add
     these attributes prior to sending an Access-Accept/EAP-Success message
     to the NAS.
     
     
     6.  Attributes
     
     
     6.1.  EAP-Message
     
     Description
     
        This attribute encapsulates Extensible Authentication Protocol  [1]
        packets  so  as  to allow the NAS to authenticate dial-in users via
        EAP without having to understand the protocol.
     
        The NAS places EAP messages received from the  authenticating  peer
        into  one  or  more EAP-Message attributes and forwards them to the
        RADIUS Server within an Access-Request message. The  RADIUS  Server
        may  then return EAP message in Access-Challenge, Access-Accept and
        Access-Reject packets.
     
        Access-Request packets including one or more EAP-Message attributes
        MUST also contain a Signature attribute, described in [5], in order
        to provide for authentication of the shuttled EAP packets.  Access-
        Requests  including  an  EAP-Message  attribute without a Signature
        attribute SHOULD be silently discarded  by  the  RADIUS  server.  A
        RADIUS  Server  supporting  EAP-Message  MUST calculate the correct
        value of the Signature and silently discard the packet if  it  does
        not  match the value sent.  A RADIUS Server not supporting EAP-Mes-
        sage MUST return an Access-Reject. A RADIUS  Server  receiving  EAP
        messages  that  it  does  not  understand  SHOULD return an Access-
        Reject.
     
     A summary of the EAP-Message attribute format  is  shown  below.   The
     fields are transmitted from left to right.
     
     
     
     Calhoun, Rubens & Aboba                                       [Page 9]


     INTERNET-DRAFT                                        19 February 1997
     
     
     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     |     Sequence No.              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      String...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
     Type
     
        67 for EAP-Message
     
     Length
     
        >=5 (EAP packet enclosed)
        =2  (EAP start message)
     
     Sequence Number
     
        The  Sequence  Number field, which is two octets in length, is used
        in order to build a "history" of the transaction.  The  EAP-Message
        attribute with the highest identifier represents the current packet
        to  process.   The  history  is  passed  along  in   each   Access-
        request/Access-Challenge  in order to support the concept of RADIUS
        backup servers, as described earlier.
     
        EAP-Message attributes with the same sequence number are to be con-
        catenated,  in  order  to allow an EAP packet to be larger than the
        253 octet limit for a RADIUS attribute.
     
     String
     
        The String field includes EAP packets, as defined in [1]:
     
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |      Code     | Identifier    |          Length               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        /                                                               /
        /                        Data                                   /
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     
     
     7.  Acknowledgments
     
     Thanks to Dave Dawson and Karl Fox of Ascend, and Glen Zorn and Naren-
     dra Gidwani of Microsoft for useful discussions of this problem space.
     
     
     8.  References
     
     [1] L. J. Blunk, J. R.  Vollbrecht.   "PPP  Extensible  Authentication
     Protocol  (EAP)."  draft-ietf-pppext-eap-auth-02.txt,  Merit  Network,
     
     
     
     Calhoun, Rubens & Aboba                                      [Page 10]


     INTERNET-DRAFT                                        19 February 1997
     
     
     Inc., June, 1996.
     
     [2] A. Rubens, P.R. Calhoun.  "DIAMETER Extensible Authentication Pro-
     tocol   Support."  draft-calhoun-diameter-eap-00.txt,  Merit  Network,
     Inc., US Robotics Access Corp., February, 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]  C.  Rigney,  W. Willats.  "RADIUS Extensions." draft-ietf-radius-
     ext-00.txt, Livingston, January, 1997.
     
     [6] R. Rivest, S. Dusse.   "The  MD5  Message-Digest  Algorithm",  RFC
     1321,  MIT  Laboratory  for  Computer Science, RSA Data Security Inc.,
     April 1992.
     
     [7] S. Bradner.  "Key words for use in RFCs  to  Indicate  Requirement
     Levels."  draft-bradner-key-words-02.txt,  Harvard University, August,
     1996.
     
     
     
     9.  Authors' Addresses
     
     Pat R. Calhoun
     US Robotics Access Corp.
     8100 N. McCormick Blvd.
     Skokie, IL 60076-2999
     
     Phone: 847-342-6898
     EMail: pcalhoun@usr.com
     
     Allan C. Rubens
     Merit Network, Inc.
     4251 Plymouth Rd.
     Ann Arbor, MI 48105-2785
     
     Phone: 313-647-0417
     EMail: acr@merit.edu
     
     Bernard Aboba
     Microsoft Corporation
     One Microsoft Way
     Redmond, WA 98052
     
     Phone: 206-936-6605
     EMail: bernarda@microsoft.com
     
     
     
     
     
     
     Calhoun, Rubens & Aboba                                      [Page 11]


     INTERNET-DRAFT                                        19 February 1997
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Calhoun, Rubens & Aboba                                      [Page 12]