home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-radius-eap-01.txt < prev    next >
Text File  |  1997-03-03  |  32KB  |  792 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.      RADIUS Working Group                                       Pat Calhoun
  7.      INTERNET-DRAFT                                US Robotics Access Corp.
  8.      <draft-ietf-radius-eap-01.txt>                         Allan C. Rubens
  9.      28 February 1997                                   Merit Network, Inc.
  10.                                                               Bernard Aboba
  11.                                                                   Microsoft
  12.  
  13.  
  14.               Extensible Authentication Protocol Support in RADIUS
  15.  
  16.  
  17.      1.  Status of this Memo
  18.  
  19.      This document is an Internet-Draft.  Internet-Drafts are working docu-
  20.      ments of the Internet Engineering Task Force (IETF),  its  areas,  and
  21.      its  working groups.  Note that other groups may also distribute work-
  22.      ing documents as Internet-Drafts.
  23.  
  24.      Internet-Drafts are draft documents valid for a maximum of six  months
  25.      and  may  be updated, replaced, or obsoleted by other documents at any
  26.      time.  It is inappropriate to use Internet-Drafts as  reference  mate-
  27.      rial or to cite them other than as ``work in progress.''
  28.  
  29.      To  learn  the  current status of any Internet-Draft, please check the
  30.      ``1id-abstracts.txt'' listing contained in the Internet-Drafts  Shadow
  31.      Directories   on   ds.internic.net   (US  East  Coast),  nic.nordu.net
  32.      (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
  33.  
  34.      The  distribution  of  this memo is unlimited.  It is filed as <draft-
  35.      ietf-radius-eap-01.txt>, and  expires September 1, 1997.  Please  send
  36.      comments to the authors.
  37.  
  38.  
  39.      2.  Abstract
  40.  
  41.      The  Extensible  Authentication Protocol (EAP) is a PPP extension that
  42.      provides support for additional  authentication  methods  within  PPP.
  43.      This  document  describes how the EAP-Message and Signature attributes
  44.      may be used for providing EAP support within RADIUS.
  45.  
  46.  
  47.      3.  Introduction
  48.  
  49.      The Extensible Authentication Protocol (EAP), described in  [1],  pro-
  50.      vides  a  standard  mechanism for support of additional authentication
  51.      methods within PPP.  Through the use of EAP, support for a  number  of
  52.      authentication  schemes may be added, including token cards, Kerberos,
  53.      Public Key, One Time Passwords, and others.  In order to  provide  for
  54.      support of EAP within RADIUS, two new attributes, EAP-Message and Sig-
  55.      nature, were introduced as RADIUS extensions  in  [5].  This  document
  56.      describes  how these new attributes may be used for providing EAP sup-
  57.      port within RADIUS.
  58.  
  59.  
  60.  
  61.  
  62.  
  63.      Calhoun, Rubens & Aboba                                       [Page 1]
  64.  
  65.  
  66.  
  67.  
  68.  
  69.      INTERNET-DRAFT                                        28 February 1997
  70.  
  71.  
  72.      The scheme described here is similar to that proposed in [2], in  that
  73.      the  RADIUS  server is used to shuttle RADIUS-encapsulated EAP Packets
  74.      between the NAS and a backend security server. While the  conversation
  75.      between  the RADIUS server  and the backend security server will typi-
  76.      cally occur using a proprietary  protocol  developed  by  the  backend
  77.      security server vendor, it is also possible to use RADIUS-encapsulated
  78.      EAP via the EAP-Message attribute. This has the advantage of  allowing
  79.      the  RADIUS server to support EAP without the need for authentication-
  80.      specific code, which can instead reside on a backend security  server.
  81.  
  82.  
  83.      3.1.  Requirements language
  84.  
  85.      This specification uses the same words as [7] for defining the signif-
  86.      icance of each particular requirement.  These words are:
  87.  
  88.  
  89.      MUST      This word, or the adjectives "REQUIRED"  or  "SHALL",  means
  90.                that the definition is an absolute requirement of the speci-
  91.                fication.
  92.  
  93.      MUST NOT  This phrase, or the phrase "SHALL NOT", means that the defi-
  94.                nition is an absolute prohibition of the specification.
  95.  
  96.      SHOULD    This  word, or the adjective "RECOMMENDED", means that there
  97.                may exist  valid  reasons  in  particular  circumstances  to
  98.                ignore  a particular item, but the full implications must be
  99.                understood and carefully weighed before choosing a different
  100.                course.
  101.  
  102.      SHOULD NOT
  103.                This phrase means that there may exist valid reasons in par-
  104.                ticular  circumstances  when  the  particular  behavior   is
  105.                acceptable  or even useful, but the full implications should
  106.                be understood and the case carefully weighed  before  imple-
  107.                menting any behavior described with this label.
  108.  
  109.      MAY       This  word,  or the adjective "OPTIONAL", means that an item
  110.                is truly optional.  One vendor may  choose  to  include  the
  111.                item because a particular marketplace requires it or because
  112.                the vendor feels that it enhances the product while  another
  113.                vendor may omit the same item.  An implementation which does
  114.                not include a particular option MUST be prepared to interop-
  115.                erate  with  another  implementation  which does include the
  116.                option, though perhaps with reduced  functionality.  In  the
  117.                same  vein an implementation which does include a particular
  118.                option MUST be prepared to interoperate with another  imple-
  119.                mentation  which  does  not  include  the option.(except, of
  120.                course, for the feature the option provides)
  121.  
  122.      An implementation is not compliant if it fails to satisfy one or  more
  123.      of  the must or must not requirements for the protocols it implements.
  124.      An implementation that satisfies all the must, must  not,  should  and
  125.      should   not   requirements   for   its   protocols   is  said  to  be
  126.  
  127.  
  128.  
  129.      Calhoun, Rubens & Aboba                                       [Page 2]
  130.  
  131.  
  132.  
  133.  
  134.  
  135.      INTERNET-DRAFT                                        28 February 1997
  136.  
  137.  
  138.      "unconditionally compliant"; one that satisfies all the must and  must
  139.      not requirements but not all the should or should not requirements for
  140.      its protocols is said to be "conditionally compliant."
  141.  
  142.  
  143.      4.  Protocol overview
  144.  
  145.      The EAP conversation between  the  authenticating  peer  and  the  NAS
  146.      begins with the negotiation of EAP within LCP. Once EAP has been nego-
  147.      tiated, the NAS will typically send to  the  RADIUS  server  a  RADIUS
  148.      Access-Request  packet  containing an EAP-Message attribute signifying
  149.      EAP-Start. EAP-Start is indicated by sending an EAP-Message  attribute
  150.      with  a length of 2 (no data). The Port number and NAS Identifier MUST
  151.      be included in the attributes issued by the NAS in the  Access-Request
  152.      packet.
  153.  
  154.      If  the  RADIUS  server  supports EAP, it MUST respond with an Access-
  155.      Challenge packet containing an EAP-Message attribute. The  EAP-Message
  156.      attribute  includes an encapsulated EAP packet which is then passed on
  157.      to the authenticating peer. The Access-Challenge typically  will  con-
  158.      tain  an  EAP-Message  attribute encapsulating an EAP-Request/Identity
  159.      message, requesting the authenticating peer to  identify  itself.  The
  160.      NAS  will  then respond with a RADIUS Access-Request packet containing
  161.      an EAP-Message attribute encapsulating an EAP-Response, etc. The  con-
  162.      versation  continues  until  either  a  RADIUS Access-Reject packet is
  163.      received (with an  EAP-Message  attribute  encapsulating  EAP-Failure)
  164.      which  results  in the NAS disconnecting the user, or a RADIUS Access-
  165.      Accept packet is received (with an EAP-Message attribute encapsulating
  166.      EAP-Success)  successfully ending the authentication phase.  Note that
  167.      if a RADIUS Access-Reject packet with an EAP-Message attribute  encap-
  168.      sulating  EAP-Failure  is  received  from  the  RADIUS Server, the NAS
  169.      SHOULD issue an LCP Terminate Request to the authenticating peer.
  170.  
  171.      The above scenario creates a situation in which the NAS never needs to
  172.      manipulate  an  EAP  packet.  An alternative may be used in situations
  173.      where an EAP-Request/Identity message will always be sent by  the  NAS
  174.      to  the authenticating peer. This involves having the NAS send an EAP-
  175.      Request/Identity message to the authenticating  peer,  and  forwarding
  176.      the  EAP-Response/Identity packet to the RADIUS server in the EAP-Mes-
  177.      sage attribute of a RADIUS Access-Request packet. While this  approach
  178.      will  save a round-trip, it cannot be universally employed.  There are
  179.      circumstances in which the user's identity may not be needed (such  as
  180.      when  authentication and accounting is handled based on the calling or
  181.      called phone number), and therefore an EAP-Request/Identity packet may
  182.      not necessarily be issued by the NAS to the authenticating peer.
  183.  
  184.      Unless the NAS interprets the EAP-Response/Identity packet returned by
  185.      the authenticating peer, it will not have access to the  user's  iden-
  186.      tity.  Therefore,  the RADIUS Server SHOULD return the user's identity
  187.      by inserting it in the User-Name attribute of subsequent  Access-Chal-
  188.      lenge and Access-Accept packets. Without the user's identity, account-
  189.      ing and billing becomes very difficult to manage.
  190.  
  191.  
  192.  
  193.  
  194.  
  195.      Calhoun, Rubens & Aboba                                       [Page 3]
  196.  
  197.  
  198.  
  199.  
  200.  
  201.      INTERNET-DRAFT                                        28 February 1997
  202.  
  203.  
  204.      In cases where a backup RADIUS servers is available, were the  primary
  205.      server  to  fail  at any time during the EAP conversation, it would be
  206.      desirable for the NAS to be able to redirect the  conversation  to  an
  207.      alternate  RADIUS server. However, for the backup server to be able to
  208.      pick up the conversation, it must be provided with the  state  of  the
  209.      EAP conversation prior to the interruption.
  210.  
  211.      This  can  be accomplished by having the RADIUS Access-Request include
  212.      the series of EAP-Message attributes representing the previous history
  213.      of  the  EAP conversation. Similarly, the RADIUS Challenge returned by
  214.      the  RADIUS  server  must  also  include  all   previous   EAP-Message
  215.      attributes.  The  sequence  number  field in the EAP-Message attribute
  216.      MUST be used in order to determine which attribute is to be processed.
  217.      The  attribute  with  the  highest  sequence number is the most recent
  218.      attribute.
  219.  
  220.      The RADIUS Access-Accept/EAP-Message/EAP-Success packet  MUST  contain
  221.      all  of  the  expected  attributes  which are currently returned in an
  222.      Access-Accept packet.
  223.  
  224.      For proxied RADIUS requests there are two methods of  processing.   If
  225.      the domain is determined based on the DNIS the RADIUS Server may proxy
  226.      the initial RADIUS Access-Request/EAP-Start. If the domain  is  deter-
  227.      mined  based  on  the  user's  identity,  the local RADIUS Server MUST
  228.      respond  with  a  RADIUS  Access-Challenge/EAP-Identity  packet.   The
  229.      response  from  the  authenticating  peer MUST be proxied to the final
  230.      authentication server.
  231.  
  232.      For proxied RADIUS requests, the  NAS  may  receive  an  Access-Reject
  233.      packet  in  response  to its Access-Request/EAP-Identity packet.  This
  234.      would occur if the message was proxied to a RADIUS Server  which  does
  235.      not  support  the  EAP-Message extension.  At this point, the NAS MUST
  236.      re-open LCP with the authenticating peer and request  either  CHAP  or
  237.      PAP  as  the  authentication  protocol.  Again,  such an Access-Reject
  238.      packet indicating lack of EAP capability will not contain an  EAP-Mes-
  239.      sage attribute.
  240.  
  241.      If  the  NAS  is unable to negotiate EAP with the authenticating peer,
  242.      what happens next is a matter of policy. In circumstances where EAP is
  243.      required  of  all users accessing the NAS, the NAS MUST disconnect the
  244.      user. However, in circumstances where EAP is mandatory for some users,
  245.      and  optional  or not required for others, the decision cannot be made
  246.      until the user's identity is ascertained. In this case, the  NAS  will
  247.      negotiate  another  authentication method, such as CHAP, and will pass
  248.      the User-Name and CHAP-Password attributes to the RADIUS Server in  an
  249.      Access-Request  packet.  If  the user is not required to use EAP, then
  250.      the RADIUS Server will respond with an Access-Accept or  Access-Reject
  251.      packet  as appropriate. However, should the user require EAP, then the
  252.      RADIUS Server will respond with an Access-Challenge packet  containing
  253.      an EAP-Message attribute. The EAP-Message attribute will either encap-
  254.      sulate an EAP-Request/Identity packet, or if the RADIUS  Server  makes
  255.      use  of the User-Name attribute in the Access-Request, it may encapsu-
  256.      late an EAP challenge. On receiving the EAP-Message attribute, the NAS
  257.      will either attempt to negotiate EAP if it had not done so previously,
  258.  
  259.  
  260.  
  261.      Calhoun, Rubens & Aboba                                       [Page 4]
  262.  
  263.  
  264.  
  265.  
  266.  
  267.      INTERNET-DRAFT                                        28 February 1997
  268.  
  269.  
  270.      or if negotiation had previously been attempted and  failed,  it  MUST
  271.      disconnect the user.
  272.  
  273.      The NAS is not responsible for the retransmission of any EAP messages.
  274.      The authenticating peer and the RADIUS Server are responsible for  any
  275.      retransmissions.
  276.  
  277.      The  example  below  shows the conversation between the authenticating
  278.      peer, NAS, and RADIUS server, for the case  of  a  One  Time  Password
  279.      (OTP)  authentication.  OTP  is  used  only for illustrative purposes;
  280.      other authentication protocols could also  have  been  used,  although
  281.      they  would show somewhat different behavior. For brevity, the history
  282.      of previous EAP messages (which will be transmitted  in  each  Access-
  283.      Request and Access-Challenge packet) has been left out.
  284.  
  285.  
  286.      Authenticating Peer     NAS                      RADIUS Server
  287.      -------------------     ---                      -------------
  288.  
  289.                              <- PPP LCP Request-EAP
  290.                              auth
  291.      PPP LCP ACK-EAP
  292.      auth ->
  293.                              RADIUS
  294.                              Access-Request/
  295.                              EAP-Message/Start ->
  296.                                                       <- RADIUS
  297.                                                       Access-Challenge/
  298.                                                       EAP-Message/Identity
  299.                              <- PPP EAP-Request/
  300.                              Identity
  301.      PPP EAP-Response/
  302.      Identity (MyID) ->
  303.                              RADIUS
  304.                              Access-Request/
  305.                              EAP-Message/
  306.                              EAP-Response/
  307.                              (MyID) ->
  308.                                                        <- RADIUS
  309.                                                        Access-Challenge/
  310.                                                        EAP-Message/EAP-Request
  311.                                                        OTP/OTP Challenge
  312.                              <- PPP EAP-Request/
  313.                              OTP/OTP Challenge
  314.      PPP EAP-Response/
  315.      OTP, OTPpw ->
  316.                              RADIUS
  317.                              Access-Request/
  318.                              EAP-Message/
  319.                              EAP-Response/
  320.                              OTP, OTPpw ->
  321.                                                         <- RADIUS
  322.                                                         Access-Accept/
  323.                                                         EAP-Message/EAP-Success
  324.  
  325.  
  326.  
  327.      Calhoun, Rubens & Aboba                                       [Page 5]
  328.  
  329.  
  330.  
  331.  
  332.  
  333.      INTERNET-DRAFT                                        28 February 1997
  334.  
  335.  
  336.                                                         (other attributes)
  337.                              <- PPP EAP-Success
  338.      PPP Authentication
  339.      Phase complete,
  340.      NCP Phase starts
  341.  
  342.      In  the  case  where  the  NAS  sends  the authenticating peer an EAP-
  343.      Request/Identity packet without first sending an EAP-Start  packet  to
  344.      the RADIUS server,  the conversation would appear as follows:
  345.  
  346.      Authenticating Peer     NAS                      RADIUS Server
  347.      -------------------     ---                      -------------
  348.  
  349.                              <- PPP LCP Request-EAP
  350.                              auth
  351.      PPP LCP ACK-EAP
  352.      auth ->
  353.                              <- PPP EAP-Request/
  354.                              Identity
  355.      PPP EAP-Response/
  356.      Identity (MyID) ->
  357.                              RADIUS
  358.                              Access-Request/
  359.                              EAP-Message/
  360.                              EAP-Response/
  361.                              (MyID) ->
  362.                                                        <- RADIUS
  363.                                                        Access-Challenge/
  364.                                                        EAP-Message/EAP-Request
  365.                                                        OTP/OTP Challenge
  366.                              <- PPP EAP-Request/
  367.                              OTP/OTP Challenge
  368.      PPP EAP-Response/
  369.      OTP, OTPpw ->
  370.                              RADIUS
  371.                              Access-Request/
  372.                              EAP-Message/
  373.                              EAP-Response/
  374.                              OTP, OTPpw ->
  375.                                                         <- RADIUS
  376.                                                         Access-Accept/
  377.                                                         EAP-Message/EAP-Success
  378.                                                         (other attributes)
  379.                              <- PPP EAP-Success
  380.      PPP Authentication
  381.      Phase complete,
  382.      NCP Phase starts
  383.  
  384.      In  the  case where the client fails EAP authentication, the conversa-
  385.      tion would appear as follows:
  386.  
  387.  
  388.      Authenticating Peer     NAS                      RADIUS Server
  389.      -------------------     ---                      -------------
  390.  
  391.  
  392.  
  393.      Calhoun, Rubens & Aboba                                       [Page 6]
  394.  
  395.  
  396.  
  397.  
  398.  
  399.      INTERNET-DRAFT                                        28 February 1997
  400.  
  401.  
  402.                              <- PPP LCP Request-EAP
  403.                              auth
  404.      PPP LCP ACK-EAP
  405.      auth ->
  406.                              Access-Request/
  407.                              EAP-Message/Start ->
  408.                                                       <- RADIUS
  409.                                                       Access-Challenge/
  410.                                                       EAP-Message/Identity
  411.                              <- PPP EAP-Request/
  412.                              Identity
  413.      PPP EAP-Response/
  414.      Identity (MyID) ->
  415.                              RADIUS
  416.                              Access-Request/
  417.                              EAP-Message/
  418.                              EAP-Response/
  419.                              (MyID) ->
  420.                                                        <- RADIUS
  421.                                                        Access-Challenge/
  422.                                                        EAP-Message/EAP-Request
  423.                                                        OTP/OTP Challenge
  424.                              <- PPP EAP-Request/
  425.                              OTP/OTP Challenge
  426.      PPP EAP-Response/
  427.      OTP, OTPpw ->
  428.                              RADIUS
  429.                              Access-Request/
  430.                              EAP-Message/
  431.                              EAP-Response/
  432.                              OTP, OTPpw ->
  433.                                                         <- RADIUS
  434.                                                         Access-Reject/
  435.                                                         EAP-Message/EAP-Failure
  436.                              <- PPP EAP-Failure
  437.                              (client disconnected)
  438.  
  439.      In the case that the RADIUS server or proxy does not support  EAP-Mes-
  440.      sage, the conversation would appear as follows:
  441.  
  442.      Authenticating Peer     NAS                         RADIUS Server
  443.      -------------------     ---                         -------------
  444.  
  445.                              <- PPP LCP Request-EAP
  446.                              auth
  447.      PPP LCP ACK-EAP
  448.      auth ->
  449.                              RADIUS
  450.                              Access-Request/
  451.                              EAP-Message/Start ->
  452.                                                          <- RADIUS
  453.                                                          Access-Reject
  454.                              <- PPP LCP Request-CHAP
  455.                              auth
  456.  
  457.  
  458.  
  459.      Calhoun, Rubens & Aboba                                       [Page 7]
  460.  
  461.  
  462.  
  463.  
  464.  
  465.      INTERNET-DRAFT                                        28 February 1997
  466.  
  467.  
  468.      PPP LCP ACK-CHAP
  469.      auth ->
  470.                              <- PPP CHAP Challenge
  471.      PPP CHAP Response ->
  472.                              RADIUS
  473.                              Access-Request->
  474.                                                          <- RADIUS
  475.                                                          Access-Accept
  476.                              <- PPP LCP
  477.                              CHAP-Success
  478.      PPP Authentication
  479.      Phase complete,
  480.      NCP Phase starts
  481.  
  482.      In  the  case  where the local RADIUS Server does support EAP-Message,
  483.      but the remote RADIUS Server does not, the conversation  would  appear
  484.      as follows:
  485.  
  486.      Authenticating Peer     NAS                         RADIUS Server
  487.      -------------------     ---                         -------------
  488.  
  489.                              <- PPP LCP Request-EAP
  490.                              auth
  491.      PPP LCP ACK-EAP
  492.      auth ->
  493.                              RADIUS
  494.                              Access-Request/
  495.                              EAP-Message/Start ->
  496.                                                          <- RADIUS
  497.                                                          Access-Challenge/
  498.                                                          EAP-Message/Identity
  499.                              <- PPP EAP-Request/
  500.                              Identity
  501.      PPP EAP-Response/
  502.      Identity
  503.      (MyID) ->
  504.                              RADIUS
  505.                              Access-Request/
  506.                              EAP-Message/EAP-Response/
  507.                              (MyID) ->
  508.                                                          <- RADIUS
  509.                                                          Access-Reject
  510.                                                          (proxied from remote
  511.                                                          RADIUS Server)
  512.                              <- PPP LCP Request-CHAP
  513.                              auth
  514.      PPP LCP ACK-CHAP
  515.      auth ->
  516.                              <- PPP CHAP Challenge
  517.      PPP CHAP Response ->
  518.                              RADIUS
  519.                              Access-Request->
  520.                                                          <- RADIUS
  521.                                                          Access-Accept
  522.  
  523.  
  524.  
  525.      Calhoun, Rubens & Aboba                                       [Page 8]
  526.  
  527.  
  528.  
  529.  
  530.  
  531.      INTERNET-DRAFT                                        28 February 1997
  532.  
  533.  
  534.                                                          (proxied from remote
  535.                                                          RADIUS Server)
  536.                              <- PPP LCP
  537.                              CHAP-Success
  538.      PPP Authentication
  539.      Phase complete,
  540.      NCP Phase starts
  541.  
  542.      In  the  case  where the authenticating peer does not support EAP, but
  543.      where EAP is required for that user, the conversation would appear  as
  544.      follows:
  545.  
  546.      Authenticating Peer     NAS                         RADIUS Server
  547.      -------------------     ---                         -------------
  548.  
  549.                              <- PPP LCP Request-EAP
  550.                              auth
  551.      PPP LCP NAK-EAP
  552.      auth ->
  553.                              <- PPP LCP Request-CHAP
  554.                              auth
  555.      PPP LCP ACK-CHAP
  556.      auth ->
  557.                              <- PPP CHAP Challenge
  558.      PPP CHAP Response ->
  559.                              RADIUS
  560.                              Access-Request/
  561.                              User-Name,
  562.                              CHAP-Password ->
  563.                                                          <- RADIUS
  564.                                                          Access-Challenge/
  565.                                                          EAP-Message
  566.                              (User Disconnected)
  567.  
  568.  
  569.      5.  Alternative uses
  570.  
  571.      Currently the conversation between the backend security server and the
  572.      RADIUS server is proprietary because of lack of  standardization.   In
  573.      order to increase standardization and provide interoperability between
  574.      Radius vendors and backend security vendors, it  is  recommended  that
  575.      RADIUS-encapsulated EAP be used for this conversation.
  576.  
  577.      This  has  the  advantage of allowing the RADIUS server to support EAP
  578.      without the need for authentication-specific  code within  the  RADIUS
  579.      server.  Authentication-specific  code  can  then  reside on a backend
  580.      security server instead.
  581.  
  582.      In the case where RADIUS-encapsulated EAP is used  in  a  conversation
  583.      between  a  RADIUS  server and a backend security server, the Security
  584.      Server will  typically  return  an  Access-Accept/EAP-Success  message
  585.      without  inclusion of the expected attributes currently returned in an
  586.      Access-Accept. This means  that  the  RADIUS  server  MUST  add  these
  587.      attributes  prior  to  sending an Access-Accept/EAP-Success message to
  588.  
  589.  
  590.  
  591.      Calhoun, Rubens & Aboba                                       [Page 9]
  592.  
  593.  
  594.  
  595.  
  596.  
  597.      INTERNET-DRAFT                                        28 February 1997
  598.  
  599.  
  600.      the NAS.
  601.  
  602.  
  603.      6.  Attributes
  604.  
  605.  
  606.      6.1.  EAP-Message
  607.  
  608.      Description
  609.  
  610.         This attribute encapsulates Extensible Authentication Protocol  [1]
  611.         packets  so  as  to allow the NAS to authenticate dial-in users via
  612.         EAP without having to understand the protocol.
  613.  
  614.         The NAS places EAP messages received from the  authenticating  peer
  615.         into  one  or  more EAP-Message attributes and forwards them to the
  616.         RADIUS Server within an Access-Request message. The  RADIUS  Server
  617.         may  then return EAP message in Access-Challenge, Access-Accept and
  618.         Access-Reject packets.
  619.  
  620.         Access-Request packets including one or more EAP-Message attributes
  621.         MUST also contain a Signature attribute, described in [5], in order
  622.         to provide for authentication of the shuttled EAP packets.  Access-
  623.         Requests  including  an  EAP-Message  attribute without a Signature
  624.         attribute SHOULD be silently discarded  by  the  RADIUS  server.  A
  625.         RADIUS  Server  supporting  EAP-Message  MUST calculate the correct
  626.         value of the Signature and silently discard the packet if  it  does
  627.         not  match the value sent.  A RADIUS Server not supporting EAP-Mes-
  628.         sage MUST return an Access-Reject. A RADIUS  Server  receiving  EAP
  629.         messages  that  it  does  not  understand  SHOULD return an Access-
  630.         Reject.
  631.  
  632.      A summary of the EAP-Message attribute format  is  shown  below.   The
  633.      fields are transmitted from left to right.
  634.  
  635.      0                   1                   2                   3
  636.      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
  637.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  638.      |      Type     |    Length     |     Sequence No.              |
  639.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  640.      |      String...
  641.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  642.  
  643.      Type
  644.  
  645.         67 for EAP-Message
  646.  
  647.      Length
  648.  
  649.         >=5 (EAP packet enclosed)
  650.         =2  (EAP start message)
  651.  
  652.      Sequence Number
  653.  
  654.  
  655.  
  656.  
  657.      Calhoun, Rubens & Aboba                                      [Page 10]
  658.  
  659.  
  660.  
  661.  
  662.  
  663.      INTERNET-DRAFT                                        28 February 1997
  664.  
  665.  
  666.         The  Sequence  Number field, which is two octets in length, is used
  667.         in order to build a "history" of the transaction.  The  EAP-Message
  668.         attribute with the highest identifier represents the current packet
  669.         to  process.   The  history  is  passed  along  in   each   Access-
  670.         request/Access-Challenge  in order to support the concept of RADIUS
  671.         backup servers, as described earlier.
  672.  
  673.         EAP-Message attributes with the same sequence number are to be con-
  674.         catenated,  in  order  to allow an EAP packet to be larger than the
  675.         253 octet limit for a RADIUS attribute.
  676.  
  677.  
  678.      String
  679.  
  680.         The String field includes EAP packets, as defined in [1]:
  681.  
  682.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  683.         |      Code     | Identifier    |          Length               |
  684.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  685.         |                                                               |
  686.         /                                                               /
  687.         /                        Data                                   /
  688.         |                                                               |
  689.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  690.  
  691.  
  692.      7.  Acknowledgments
  693.  
  694.      Thanks to Dave Dawson and Karl Fox of Ascend, and Glen Zorn and Naren-
  695.      dra Gidwani of Microsoft for useful discussions of this problem space.
  696.  
  697.  
  698.      8.  References
  699.  
  700.      [1] L. J. Blunk, J. R.  Vollbrecht.   "PPP  Extensible  Authentication
  701.      Protocol  (EAP)."  draft-ietf-pppext-eap-auth-02.txt,  Merit  Network,
  702.      Inc., June, 1996.
  703.  
  704.      [2] A. Rubens, P.R. Calhoun.  "DIAMETER Extensible Authentication Pro-
  705.      tocol   Support."  draft-calhoun-diameter-eap-00.txt,  Merit  Network,
  706.      Inc., US Robotics Access Corp., February, 1997.
  707.  
  708.      [3]  C. Rigney, A. Rubens, W. Simpson, S. Willens.  "Remote  Authenti-
  709.      cation  Dial  In  User Service (RADIUS)." RFC 2058, Livingston, Merit,
  710.      Daydreamer, January, 1997.
  711.  
  712.      [4]  C. Rigney.  "RADIUS Accounting." RFC 2059,  Livingston,  January,
  713.      1997.
  714.  
  715.      [5]  C.  Rigney,  W. Willats.  "RADIUS Extensions." draft-ietf-radius-
  716.      ext-00.txt, Livingston, January, 1997.
  717.  
  718.      [6] R. Rivest, S. Dusse.   "The  MD5  Message-Digest  Algorithm",  RFC
  719.      1321,  MIT  Laboratory  for  Computer Science, RSA Data Security Inc.,
  720.  
  721.  
  722.  
  723.      Calhoun, Rubens & Aboba                                      [Page 11]
  724.  
  725.  
  726.  
  727.  
  728.  
  729.      INTERNET-DRAFT                                        28 February 1997
  730.  
  731.  
  732.      April 1992.
  733.  
  734.      [7] S. Bradner.  "Key words for use in RFCs  to  Indicate  Requirement
  735.      Levels."  draft-bradner-key-words-02.txt,  Harvard University, August,
  736.      1996.
  737.  
  738.  
  739.  
  740.      9.  Authors' Addresses
  741.  
  742.      Pat R. Calhoun
  743.      US Robotics Access Corp.
  744.      8100 N. McCormick Blvd.
  745.      Skokie, IL 60076-2999
  746.  
  747.      Phone: 847-342-6898
  748.      EMail: pcalhoun@usr.com
  749.  
  750.      Allan C. Rubens
  751.      Merit Network, Inc.
  752.      4251 Plymouth Rd.
  753.      Ann Arbor, MI 48105-2785
  754.  
  755.      Phone: 313-647-0417
  756.      EMail: acr@merit.edu
  757.  
  758.      Bernard Aboba
  759.      Microsoft Corporation
  760.      One Microsoft Way
  761.      Redmond, WA 98052
  762.  
  763.      Phone: 206-936-6605
  764.      EMail: bernarda@microsoft.com
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786.  
  787.  
  788.  
  789.      Calhoun, Rubens & Aboba                                      [Page 12]
  790.  
  791.  
  792.