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-02.txt < prev    next >
Text File  |  1997-05-22  |  32KB  |  855 lines
  1.  
  2.  
  3. RADIUS Working Group                                       Pat Calhoun
  4. INTERNET-DRAFT                                US Robotics Access Corp.
  5. Updates: RFC 2058                                      Allan C. Rubens
  6. Category: Standards Track                          Merit Network, Inc.
  7. <draft-ietf-radius-eap-02.txt>                           Bernard Aboba
  8. May 22, 1997                                                 Microsoft
  9.  
  10.  
  11.          Extensible Authentication Protocol Support in RADIUS
  12.  
  13.  
  14. 1.  Status of this Memo
  15.  
  16. This document is an Internet-Draft.  Internet-Drafts are working docu-
  17. ments  of  the  Internet Engineering Task Force (IETF), its areas, and
  18. its working groups.  Note that other groups may also distribute  work-
  19. ing documents as Internet-Drafts.
  20.  
  21. Internet-Drafts are draft documents valid for a maximum of six  months
  22. and  may  be updated, replaced, or obsoleted by other documents at any
  23. time.   It  is  inappropriate  to  use  Internet-Drafts  as  reference
  24. material or to cite them other than as ``work in progress.''
  25.  
  26. To learn the current status of any Internet-Draft,  please  check  the
  27. ``1id-abstracts.txt''  listing contained in the Internet-Drafts Shadow
  28. Directories  on  ds.internic.net  (US   East   Coast),   nic.nordu.net
  29. (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
  30.  
  31. The distribution of this memo is unlimited.  It is  filed  as  <draft-
  32. ietf-radius-eap-02.txt>,  and   expires  January  1, 1998. Please send
  33. comments to the authors.
  34.  
  35.  
  36. 2.  Abstract
  37.  
  38. The Extensible Authentication Protocol (EAP) is a PPP  extension  that
  39. provides  support  for  additional  authentication methods within PPP.
  40. This document describes how the EAP-Message and  Signature  attributes
  41. may be used for providing EAP support within RADIUS.
  42.  
  43.  
  44. 3.  Introduction
  45.  
  46. The Extensible Authentication Protocol (EAP), described in  [1],  pro-
  47. vides  a  standard  mechanism for support of additional authentication
  48. methods within PPP. Through the use of EAP, support for  a  number  of
  49. authentication  schemes may be added, including smart cards, Kerberos,
  50. Public Key, One Time Passwords, and others. In order  to  provide  for
  51. support of EAP within RADIUS, two new attributes, EAP-Message and Sig-
  52. nature, were introduced as RADIUS extensions  in  [4].  This  document
  53. describes  how these new attributes may be used for providing EAP sup-
  54. port within RADIUS.
  55.  
  56. In the proposed scheme, the RADIUS server is used to  shuttle  RADIUS-
  57.  
  58.  
  59.  
  60. Calhoun, Rubens & Aboba                                       [Page 1]
  61.  
  62.  
  63.  
  64.  
  65.  
  66. INTERNET-DRAFT                                            May 22, 1997
  67.  
  68.  
  69. encapsulated  EAP  Packets  between  the  NAS  and  a backend security
  70. server. While the conversation between  the  RADIUS  server   and  the
  71. backend  security server will typically occur using a proprietary pro-
  72. tocol developed by the backend security server vendor, it is also pos-
  73. sible  to  use  RADIUS-encapsulated EAP via the EAP-Message attribute.
  74. This has the advantage of allowing the RADIUS server  to  support  EAP
  75. without  the  need for authentication-specific code, which can instead
  76. reside on a backend security server.
  77.  
  78.  
  79. 3.1.  Requirements language
  80.  
  81. This specification uses the same words as [6] for defining the  signi-
  82. ficance of each particular requirement.  These words are:
  83.  
  84.  
  85. MUST      This word, or the adjectives "REQUIRED"  or  "SHALL",  means
  86.           that  the  definition  is  an  absolute  requirement  of the
  87.           specification.
  88.  
  89. MUST NOT  This phrase, or the  phrase  "SHALL  NOT",  means  that  the
  90.           definition is an absolute prohibition of the specification.
  91.  
  92. SHOULD    This word, or the adjective "RECOMMENDED", means that  there
  93.           may  exist  valid  reasons  in  particular  circumstances to
  94.           ignore a particular item, but the full implications must  be
  95.           understood and carefully weighed before choosing a different
  96.           course.
  97.  
  98. SHOULD NOTThis phrase means that there may exist valid reasons in par-
  99.           ticular   circumstances  when  the  particular  behavior  is
  100.           acceptable or even useful, but the full implications  should
  101.           be  understood  and the case carefully weighed before imple-
  102.           menting any behavior described with this label.
  103.  
  104. MAY       This word, or the adjective "AL",  means  that  an  item  is
  105.           truly  optional.   One vendor may choose to include the item
  106.           because a particular marketplace requires it or because  the
  107.           vendor feels that it enhances the product while another ven-
  108.           dor may omit the same item.  An  implementation  which  does
  109.           not  include a particular option MUST be prepared to intero-
  110.           perate with another implementation which  does  include  the
  111.           option,  though  perhaps  with reduced functionality. In the
  112.           same vein an implementation which does include a  particular
  113.           option  MUST be prepared to interoperate with another imple-
  114.           mentation which does  not  include  the  option.(except,  of
  115.           course, for the feature the option provides)
  116.  
  117. An implementation is not compliant if it fails to satisfy one or  more
  118. of  the must or must not requirements for the protocols it implements.
  119. An implementation that satisfies all the must, must  not,  should  and
  120. should  not requirements for its protocols is said to be "uncondition-
  121. ally compliant"; one that satisfies all the must and must not require-
  122. ments  but  not  all  the  should  or  should not requirements for its
  123.  
  124.  
  125.  
  126. Calhoun, Rubens & Aboba                                       [Page 2]
  127.  
  128.  
  129.  
  130.  
  131.  
  132. INTERNET-DRAFT                                            May 22, 1997
  133.  
  134.  
  135. protocols is said to be "conditionally compliant."
  136.  
  137.  
  138. 4.  Protocol overview
  139.  
  140. The EAP conversation between the authenticating  peer  (dial-in  user)
  141. and  the  NAS  begins with the negotiation of EAP within LCP. Once EAP
  142. has been negotiated, the NAS will typically send to the RADIUS  server
  143. a  RADIUS  Access-Request  packet  containing an EAP-Message attribute
  144. signifying EAP-Start. EAP-Start is indicated by sending an EAP-Message
  145. attribute with a length of 2 (no data). NAS-Port SHOULD be included in
  146. the attributes issued by the NAS in the Access-Request packet;  either
  147. NAS-Identifier or NAS-IP-Address MUST be included.
  148.  
  149. If the RADIUS server supports EAP, it MUST  respond  with  an  Access-
  150. Challenge  packet  containing  an EAP-Message attribute. If the RADIUS
  151. server does not support EAP, it MUST respond with an Access-Reject.
  152.  
  153. The EAP-Message attribute includes an encapsulated EAP packet which is
  154. then  passed on to the authenticating peer. The Access-Challenge typi-
  155. cally will contain an  EAP-Message  attribute  encapsulating  an  EAP-
  156. Request/Identity  message,  requesting  the  dial-in  user to identify
  157. themself. The NAS will  then  respond  with  a  RADIUS  Access-Request
  158. packet  containing  an  EAP-Message  attribute  encapsulating  an EAP-
  159. Response. The conversation continues until  either  a  RADIUS  Access-
  160. Reject or Access-Accept packet is received.
  161.  
  162. Reception of a RADIUS Access-Reject packet, with or  without  an  EAP-
  163. Message  attribute  encapsulating  EAP-Failure, MUST result in the NAS
  164. issuing an LCP Terminate Request to the authenticating peer.  A RADIUS
  165. Access-Accept  packet with an EAP-Message attribute encapsulating EAP-
  166. Success  successfully  ends  the  authentication  phase.  The   RADIUS
  167. Access-Accept/EAP-Message/EAP-Success  packet  MUST contain all of the
  168. expected attributes which are currently returned in  an  Access-Accept
  169. packet.
  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-
  177. Message attribute  of  a  RADIUS  Access-Request  packet.  While  this
  178. approach  will  save  a round-trip, it cannot be universally employed.
  179. There are circumstances in which the user's identity may not be needed
  180. (such  as  when  authentication  and  accounting  is  handled based on
  181. Called-Station-Id  or  Calling-Station-Id),  and  therefore  an   EAP-
  182. Request/Identity  packet  may  not necessarily be issued by the NAS to
  183. the authenticating peer.
  184.  
  185. Unless the NAS interprets the EAP-Response/Identity packet returned by
  186. the  authenticating  peer, it will not have access to the user's iden-
  187. tity. Therefore, the RADIUS Server SHOULD return the  user's  identity
  188. by  inserting  it  in  the  User-Name  attribute of subsequent Access-
  189.  
  190.  
  191.  
  192. Calhoun, Rubens & Aboba                                       [Page 3]
  193.  
  194.  
  195.  
  196.  
  197.  
  198. INTERNET-DRAFT                                            May 22, 1997
  199.  
  200.  
  201. Challenge and Access-Accept  packets.  Without  the  user's  identity,
  202. accounting and billing becomes very difficult to manage.
  203.  
  204. For proxied RADIUS requests there are two methods of  processing.   If
  205. the  domain  is  determined based on the Called-Station-Id, the RADIUS
  206. Server may proxy the initial RADIUS Access-Request/EAP-Start.  If  the
  207. domain  is  determined  based on the user's identity, the local RADIUS
  208. Server  MUST  respond  with  a  RADIUS   Access-Challenge/EAP-Identity
  209. packet.  The  response from the authenticating peer MUST be proxied to
  210. the final authentication server.
  211.  
  212. For proxied RADIUS requests, the  NAS  may  receive  an  Access-Reject
  213. packet  in  response  to  its Access-Request/EAP-Identity packet. This
  214. would occur if the message was proxied to a RADIUS Server  which  does
  215. not  support the EAP-Message extension. On receiving an Access-Reject,
  216. the NAS MUST send an LCP Terminate Request to the authenticating peer,
  217. and disconnect.
  218.  
  219. The NAS is not responsible for the retransmission of any AP  messages.
  220. The  authenticating peer and the RADIUS Server are responsible for any
  221. retransmissions.
  222.  
  223. The example below shows the conversation  between  the  authenticating
  224. peer,  NAS,  and  RADIUS  server,  for the case of a One Time Password
  225. (OTP) authentication. OTP is  used  only  for  illustrative  purposes;
  226. other  authentication  protocols  could  also have been used, although
  227. they might show somewhat different behavior.
  228.  
  229.  
  230. Authenticating Peer     NAS                      RADIUS Server
  231. -------------------     ---                      -------------
  232.  
  233.                         <- PPP LCP Request-EAP
  234.                         auth
  235. PPP LCP ACK-EAP
  236. auth ->
  237.                         RADIUS
  238.                         Access-Request/
  239.                         EAP-Message/Start ->
  240.                                                  <- RADIUS
  241.                                                  Access-Challenge/
  242.                                                  EAP-Message/Identity
  243.                         <- PPP EAP-Request/
  244.                         Identity
  245. PPP EAP-Response/
  246. Identity (MyID) ->
  247.                         RADIUS
  248.                         Access-Request/
  249.                         EAP-Message/
  250.                         EAP-Response/
  251.                         (MyID) ->
  252.                                                   <- RADIUS
  253.                                                   Access-Challenge/
  254.                                                   EAP-Message/EAP-Request
  255.  
  256.  
  257.  
  258. Calhoun, Rubens & Aboba                                       [Page 4]
  259.  
  260.  
  261.  
  262.  
  263.  
  264. INTERNET-DRAFT                                            May 22, 1997
  265.  
  266.  
  267.                                                   OTP/OTP Challenge
  268.                         <- PPP EAP-Request/
  269.                         OTP/OTP Challenge
  270. PPP EAP-Response/
  271. OTP, OTPpw ->
  272.                         RADIUS
  273.                         Access-Request/
  274.                         EAP-Message/
  275.                         EAP-Response/
  276.                         OTP, OTPpw ->
  277.                                                    <- RADIUS
  278.                                                    Access-Accept/
  279.                                                    EAP-Message/EAP-Success
  280.                                                    (other attributes)
  281.                         <- PPP EAP-Success
  282. PPP Authentication
  283. Phase complete,
  284. NCP Phase starts
  285.  
  286. In the case where the  NAS  sends  the  authenticating  peer  an  EAP-
  287. Request/Identity  packet  without first sending an EAP-Start packet to
  288. the RADIUS server,  the conversation would appear as follows:
  289.  
  290. Authenticating Peer     NAS                      RADIUS Server
  291. -------------------     ---                      -------------
  292.  
  293.                         <- PPP LCP Request-EAP
  294.                         auth
  295. PPP LCP ACK-EAP
  296. auth ->
  297.                         <- PPP EAP-Request/
  298.                         Identity
  299. PPP EAP-Response/
  300. Identity (MyID) ->
  301.                         RADIUS
  302.                         Access-Request/
  303.                         EAP-Message/
  304.                         EAP-Response/
  305.                         (MyID) ->
  306.                                                   <- RADIUS
  307.                                                   Access-Challenge/
  308.                                                   EAP-Message/EAP-Request
  309.                                                   OTP/OTP Challenge
  310.                         <- PPP EAP-Request/
  311.                         OTP/OTP Challenge
  312. PPP EAP-Response/
  313. OTP, OTPpw ->
  314.                         RADIUS
  315.                         Access-Request/
  316.                         EAP-Message/
  317.                         EAP-Response/
  318.                         OTP, OTPpw ->
  319.                                                    <- RADIUS
  320.                                                    Access-Accept/
  321.  
  322.  
  323.  
  324. Calhoun, Rubens & Aboba                                       [Page 5]
  325.  
  326.  
  327.  
  328.  
  329.  
  330. INTERNET-DRAFT                                            May 22, 1997
  331.  
  332.  
  333.                                                    EAP-Message/EAP-Success
  334.                                                    (other attributes)
  335.                         <- PPP EAP-Success
  336. PPP Authentication
  337. Phase complete,
  338. NCP Phase starts
  339.  
  340. In the case where the client fails EAP authentication,  the  conversa-
  341. tion would appear as follows:
  342.  
  343.  
  344. Autheticating Peer     NAS                      RADIUS Server
  345. -------------------     ---                      -------------
  346.  
  347.                         <- PPP LCP Request-EAP
  348.                         auth
  349. PPP LCP ACK-EAP
  350. auth ->
  351.                         Access-Request/
  352.                         EAP-Message/Start ->
  353.                                                  <- RADIUS
  354.                                                  Access-Challenge/
  355.                                                  EAP-Message/Identity
  356.                         <- PPP EAP-Request/
  357.                         Identity
  358. PPP EAP-Response/
  359. Identity (MyID) ->
  360.                         RADIUS
  361.                         Access-Request/
  362.                         EAP-Message/
  363.                         EAP-Response/
  364.                         (MyID) ->
  365.                                                   <- RADIUS
  366.                                                   Access-Challenge/
  367.                                                   EAP-Message/EAP-Request
  368.                                                   OTP/OTP Challenge
  369.                         <- PPP EAP-Request/
  370.                         OTP/OTP Challenge
  371. PPP EAP-Response/
  372. OTP, OTPpw ->
  373.                         RADIUS
  374.                         Access-Request/
  375.                         EAP-Message/
  376.                         EAP-Response/
  377.                         OTP, OTPpw ->
  378.                                                    <- RADIUS
  379.                                                    Access-Reject/
  380.                                                    EAP-Message/EAP-Failure
  381.                         <- PPP EAP-Failure
  382.                         (client disconnected)
  383.  
  384. In the case that the RADIUS server or  proxy  does  not  support  EAP-
  385. Message, the conversation would appear as follows:
  386.  
  387.  
  388.  
  389.  
  390. Calhoun, Rubens & Aboba                                       [Page 6]
  391.  
  392.  
  393.  
  394.  
  395.  
  396. INTERNET-DRAFT                                            May 22, 1997
  397.  
  398.  
  399. Authenticating Peer     NAS                         RADIUS Server
  400. -------------------     ---                         -------------
  401.  
  402.                         <- PPP LCP Request-EAP
  403.                         auth
  404. PPP LCP ACK-EAP
  405. auth ->
  406.                         RADIUS
  407.                         Access-Request/
  408.                         EAP-Message/Start ->
  409.                                                     <- RADIUS
  410.                                                     Access-Reject
  411.                         <- PPP LCP Terminate
  412.                         (User Disconnected)
  413.  
  414. In the case where the local RADIUS Server  does  support  EAP-Message,
  415. but  the  remote RADIUS Server does not, the conversation would appear
  416. as follows:
  417.  
  418. Authenticating Peer     NAS                         RADIUS Server
  419. -------------------     ---                         -------------
  420.  
  421.                         <- PPP LCP Request-EAP
  422.                         auth
  423. PPP LCP ACK-EAP
  424. auth ->
  425.                         RADIUS
  426.                         Access-Request/
  427.                         EAP-Message/Start ->
  428.                                                     <- RADIUS
  429.                                                     Access-Challenge/
  430.                                                     EAP-Message/Identity
  431.                         <- PPP EAP-Request/
  432.                         Identity
  433. PPP EAP-Response/
  434. Identity
  435. (MyID) ->
  436.                         RADIUS
  437.                         Access-Request/
  438.                         EAP-Message/EAP-Response/
  439.                         (MyID) ->
  440.                                                     <- RADIUS
  441.                                                     Access-Reject
  442.                                                     (proxied from remote
  443.                                                     RADIUS Server)
  444.                         <- PPP LCP Terminate
  445.                         (User Disconnected)
  446.  
  447. In the case where the authenticating peer does not  support  EAP,  but
  448. where  EAP is required for that user, the conversation would appear as
  449. follows:
  450.  
  451. Authenticating Peer     NAS                         RADIUS Server
  452. -------------------     ---                         -------------
  453.  
  454.  
  455.  
  456. Calhoun, Rubens & Aboba                                       [Page 7]
  457.  
  458.  
  459.  
  460.  
  461.  
  462. INTERNET-DRAFT                                            May 22, 1997
  463.  
  464.  
  465.                         <- PPP LCP Request-EAP
  466.                         auth
  467. PPP LCP NAK-EAP
  468. auth ->
  469.                         <- PPP LCP Request-CHAP
  470.                         auth
  471. PPP LCP ACK-CHAP
  472. auth ->
  473.                         <- PPP CHAP Challenge
  474. PPP CHAP Response ->
  475.                         RADIUS
  476.                         Access-Request/
  477.                         User-Name,
  478.                         CHAP-Password ->
  479.                                                     <- RADIUS
  480.                                                     Access-Reject
  481.                         <-  PPP LCP Terminate
  482.                         (User Disconnected)
  483.  
  484. In the case where the NAS does not  support  EAP,  but  where  EAP  is
  485. required for that user, the conversation would appear as follows:
  486.  
  487. Authenticating Peer     NAS                         RADIUS Server
  488. -------------------     ---                         -------------
  489.  
  490.                         <- PPP LCP Request-CHAP
  491.                         auth
  492. PP LCP ACK-CHAP
  493. auth ->
  494.                         <- PPP CHAP Challenge
  495. PPP CHAP Response ->
  496.                         RADIUS
  497.                         Access-Request/
  498.                         User-Name,
  499.                         CHAP-Password ->
  500.                                                     <- RADIUS
  501.                                                     Access-Reject
  502.                         <-  PPP LCP Terminate
  503.                         (User Disconnected)
  504.  
  505.  
  506. 5.  Alternative uses
  507.  
  508. Currently the conversation between the backend security server and the
  509. RADIUS  server  is proprietary because of lack of standardization.  In
  510. order to increase standardization and provide interoperability between
  511. Radius  vendors  and  backend security vendors, it is recommended that
  512. RADIUS-encapsulated EAP be used for this conversation.
  513.  
  514. This has the advantage of allowing the RADIUS server  to  support  EAP
  515. without  the  need for authentication-specific  code within the RADIUS
  516. server. Authentication-specific code can  then  reside  on  a  backend
  517. security server instead.
  518.  
  519.  
  520.  
  521.  
  522. Calhoun, Rubens & Aboba                                       [Page 8]
  523.  
  524.  
  525.  
  526.  
  527.  
  528. INTERNET-DRAFT                                            May 22, 1997
  529.  
  530.  
  531. In the case where RADIUS-encapsulated EAP is used  in  a  conversation
  532. between  a  RADIUS  server and a backend security server, the security
  533. server will  typically  return  an  Access-Accept/EAP-Success  message
  534. without  inclusion of the expected attributes currently returned in an
  535. Access-Accept. This means that the RADIUS server MUST add these attri-
  536. butes  prior  to  sending  an Access-Accept/EAP-Success message to the
  537. NAS.
  538.  
  539.  
  540. 6.  Attributes
  541.  
  542.  
  543. 6.1.  EAP-Message
  544.  
  545. Description
  546.  
  547.    This attribute encapsulates Extensible Authentication Protocol  [1]
  548.    packets  so  as  to allow the NAS to authenticate dial-in users via
  549.    EAP without having to understand the protocol.
  550.  
  551.    The NAS places EAP messages received from the  authenticating  peer
  552.    into  one  or  more EAP-Message attributes and forwards them to the
  553.    RADIUS Server within an Access-Request message. The  RADIUS  Server
  554.    may  return one or more EAP-Message attributes in Access-Challenge,
  555.    Access-Accept and Access-Reject packets.
  556.  
  557.    Access-Request packets including one or more EAP-Message attributes
  558.    MUST also contain a Signature attribute, described in [4], in order
  559.    to provide for authentication of the shuttled EAP packets.  Access-
  560.    Request packets including an EAP-Message attribute without a Signa-
  561.    ture attribute SHOULD be silently discarded by the RADIUS server. A
  562.    RADIUS  Server  supporting  EAP-Message  MUST calculate the correct
  563.    value of the Signature and silently discard the packet if  it  does
  564.    not  match  the  value  sent.   A RADIUS Server not supporting EAP-
  565.    Message MUST return an Access-Reject  if  it  receives  an  Access-
  566.    Reqeust  containing  an  EAP-Message  attribute.  A  RADIUS  Server
  567.    receiving an EAP-Message attribute that it does not understand MUST
  568.    return an Access-Reject.
  569.  
  570. A summary of the EAP-Message attribute format  is  shown  below.   The
  571. fields are transmitted from left to right.
  572.  
  573. 0                   1                   2                   3
  574. 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
  575. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  576. |      Type     |    Length     |            String...
  577. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  578.  
  579. Type
  580.  
  581.    67 for EAP-Message
  582.  
  583. Length
  584.  
  585.  
  586.  
  587.  
  588. Calhoun, Rubens & Aboba                                       [Page 9]
  589.  
  590.  
  591.  
  592.  
  593.  
  594. INTERNET-DRAFT                                            May 22, 1997
  595.  
  596.  
  597.    >=3 (EAP packet enclosed)
  598.    =2  (EAP-Start message)
  599.  
  600. String
  601.  
  602.    The String field includes EAP packets, as defined in [1]. If multi-
  603.    ple  EAP-Message  attributes  are  present in a packet their values
  604.    should be concatenated; this allows EAP  packets  longer  than  253
  605.    octets to be passed by RADIUS.
  606.  
  607.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  608.    |      Code     | Identifier    |          Length               |
  609.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  610.    |                                                               |
  611.    /                                                               /
  612.    /                        Data                                   /
  613.    |                                                               |
  614.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  615.  
  616.  
  617. 7.  Security considerations
  618.  
  619. Since the purpose of EAP is  to  provide  enhanced  security  for  PPP
  620. authentication,  it is critical that RADIUS support for EAP be secure.
  621. In particular, protection  must  be  provided  against  the  following
  622. attacks:
  623.  
  624.    Connection hijacking
  625.    Man in the middle attacks
  626.    Multiple databases
  627.    Negotiation attacks
  628.  
  629.  
  630. 7.1.  Connection hijacking
  631.  
  632. In this form of attack, the attacker attempts to inject  packets  into
  633. the conversation between the NAS and the RADIUS server, or between the
  634. RADIUS server and the backend security server. RADIUS does not support
  635. encryption,  and  as  described  in [2], only Access-Reply and Access-
  636. Challenge packets are authenticated.
  637.  
  638. In order to provide for authentication  of  all  packets  in  the  EAP
  639. exchange, all Access-Request/EAP-Message packets MUST be authenticated
  640. using the Signature attribute, as described in [4].  The RADIUS server
  641. MUST  silently  discard all Access-Request packets failing authentica-
  642. tion.
  643.  
  644.  
  645. 7.2.  Man in the middle attacks
  646.  
  647. Since RADIUS security is based on shared secrets, end-to-end  security
  648. is not provided in the case where authentication or accounting packets
  649. are forwarded along a proxy chain. As a result, attackers gaining con-
  650. trol  of  a RADIUS proxy will be able to modify EAP packets in transit
  651.  
  652.  
  653.  
  654. Calhoun, Rubens & Aboba                                      [Page 10]
  655.  
  656.  
  657.  
  658.  
  659.  
  660. INTERNET-DRAFT                                            May 22, 1997
  661.  
  662.  
  663. without fear of detection.
  664.  
  665. This represents a weakness of RADIUS which can be remedied  by  imple-
  666. menting RADIUS on top of IP Security.
  667.  
  668.  
  669. 7.3.  Multiple databases
  670.  
  671. In many cases a backend security server will be deployed along with  a
  672. RADIUS  server  in  order  to provide EAP services. Unless the backend
  673. security server also functions as a RADIUS server, two  separate  user
  674. databases  will  exist, each containing information about the security
  675. requirements for the user. This represents a weakness, since  security
  676. may be compromised by a successful attack on either of the servers, or
  677. their backend databases. With multiple user databases,  adding  a  new
  678. user  may  require  multiple  operations,  increasing  the chances for
  679. error. The problems are further  magnified  in  the  case  where  user
  680. information  is also being kept in an LDAP server. In this case, three
  681. stores of user information may exist.
  682.  
  683. In order to address  these  threats,  consolidation  of  databases  is
  684. recommended. This can be achieved by having both the RADIUS server and
  685. backend security server store information in the  same  backend  data-
  686. base;  by  having  the  backend  security server provide a full RADIUS
  687. implementation; or by consolidating both the backend  security  server
  688. and the RADIUS server onto the same machine.
  689.  
  690.  
  691. 7.4.  Negotiation attacks
  692.  
  693. In a negotiation attack, a rogue NAS, tunnel server, RADIUS  proxy  or
  694. RADIUS  server  causes the authenticating peer to choose a less secure
  695. authentication method so as to make it easier  to  obtain  the  user's
  696. password.  For example, a session that would normally be authenticated
  697. with EAP would instead authenticated via CHAP or PAP; alternatively, a
  698. connection  that  would  normally  be  authenticated  via one EAP type
  699. occurs via a less secure EAP type, such as MD5. The  threat  posed  by
  700. rogue  devices,  once  thought to be remote, has gained currency given
  701. compromises of telephone company  switching  systems,  such  as  those
  702. described in [7].
  703.  
  704. Protection against negotiation attacks  requires  the  elimination  of
  705. downward  negotiations.  This  can  be  achieved via implementation of
  706. per-connection policy on the part  of  the  authenticating  peer,  and
  707. per-user policy on the part of the RADIUS server.
  708.  
  709. For the authenticating peer, authentication policy should be set on  a
  710. per-connection  basis.  Per-connection policy allows an authenticating
  711. peer to negotiate EAP when calling one service, while negotiating CHAP
  712. for another service, even if both services are accessible via the same
  713. phone number.
  714.  
  715. With per-connection policy, an authenticating peer will  only  attempt
  716. to  negotiate EAP for a session in which EAP support is expected. As a
  717.  
  718.  
  719.  
  720. Calhoun, Rubens & Aboba                                      [Page 11]
  721.  
  722.  
  723.  
  724.  
  725.  
  726. INTERNET-DRAFT                                            May 22, 1997
  727.  
  728.  
  729. result, there is a presumption that an authenticating  peer  selecting
  730. EAP  requires  that level of security. If it cannot be provided, it is
  731. likely that there is some kind of misconfiguration, or even  that  the
  732. authenticating peer is contacting the wrong server. Should the NAS not
  733. be able to negotiate EAP, or should the EAP-Request sent by the NAS be
  734. of a different EAP type than what is expected, the authenticating peer
  735. MUST disconnect. An authenticating peer expecting EAP to be negotiated
  736. for a session MUST NOT negotiate CHAP or PAP.
  737.  
  738. For a NAS, it may not be possible  to  determine  whether  a  user  is
  739. required  to authenticate with EAP until the user's identity is known.
  740. For example, for shared-uses NASes it is possible for one reseller  to
  741. implement  EAP  while another does not. In such cases, if any users of
  742. the NAS MUST do EAP, then the NAS MUST attempt to  negotiate  EAP  for
  743. every  call. This avoids forcing an EAP-capable client to do more than
  744. one authentication, which weakens security.
  745.  
  746. If CHAP is negotiated, the NAS  will  pass  the  User-Name  and  CHAP-
  747. Password  attributes to the RADIUS Server in an Access-Request packet.
  748. If the user is not required to use EAP, then the  RADIUS  Server  will
  749. respond  with an Access-Accept or Access-Reject packet as appropriate.
  750. However, if CHAP has been negotiated but EAP is required,  the  RADIUS
  751. server  MUST  respond  with  an  Access-Reject, rather than an Access-
  752. Challenge/EAP-Message/EAP-Request packet. The authenticating peer MUST
  753. refuse  to  renegotiate  authentication,  even if the renegotiation is
  754. from CHAP to EAP.
  755.  
  756. If EAP is negotiated but is not  supported  by  the  RADIUS  proxy  or
  757. server,  then  the server or proxy MUST respond with an Access-Reject.
  758. In these cases, the NAS MUST send an LCP-Terminate and disconnect  the
  759. user.  This  is  the correct behavior since the authenticating peer is
  760. expecting EAP to be negotiated, and that expectation  cannot  be  ful-
  761. filled.  An EAP-capable authenticating peer MUST refuse to renegotiate
  762. the authentication protocol if  EAP  had  initially  been  negotiated.
  763. Note  that  problems  with  a non-EAP capable RADIUS proxy could prove
  764. difficult to diagnose, since a user dialing in from one location (with
  765. an  EAP-capable  proxy) might be able to successfully authenticate via
  766. EAP, while the same user dialing into another location (and encounter-
  767. ing an EAP-incapable proxy) might be consistently disconnected.
  768.  
  769.  
  770. 8.  Acknowledgments
  771.  
  772. Thanks to Dave Dawson and Karl Fox of Ascend, and Glen Zorn and Naren-
  773. dra Gidwani of Microsoft for useful discussions of this problem space.
  774.  
  775.  
  776. 9.  References
  777.  
  778. [1] L. J. Blunk, J. R.  Vollbrecht.   "PPP  Extensible  Authentication
  779. Protocol  (EAP)." Work in progress, draft-ietf-pppext-eap-auth-02.txt,
  780. Merit Network, Inc., June, 1996.
  781.  
  782. [2]   C.  Rigney,  A.  Rubens,  W.  Simpson,  S.   Willens.    "Remote
  783.  
  784.  
  785.  
  786. Calhoun, Rubens & Aboba                                      [Page 12]
  787.  
  788.  
  789.  
  790.  
  791.  
  792. INTERNET-DRAFT                                            May 22, 1997
  793.  
  794.  
  795. Authentication  Dial  In User Service (RADIUS)." RFC 2058, Livingston,
  796. Merit, Daydreamer, January, 1997.
  797.  
  798. [3]  C. Rigney.  "RADIUS Accounting." RFC 2059,  Livingston,  January,
  799. 1997.
  800.  
  801. [4] C. Rigney, W. Willats.  "RADIUS  Extensions."  Work  in  progress,
  802. draft-ietf-radius-ext-00.txt, Livingston, January, 1997.
  803.  
  804. [5] R. Rivest, S. Dusse.   "The  MD5  Message-Digest  Algorithm."  RFC
  805. 1321,  MIT  Laboratory  for  Computer Science, RSA Data Security Inc.,
  806. April 1992.
  807.  
  808. [6] S. Bradner.  "Key words for use in RFCs  to  Indicate  Requirement
  809. Levels." RFC 2119, Harvard University, March, 1997.
  810.  
  811. [7] M. Slatalla, J. Quittner.  "Masters of Deception."  HarperCollins,
  812. New York, 1995.
  813.  
  814.  
  815. 10.  Authors' Addresses
  816.  
  817. Pat R. Calhoun
  818. US Robotics Access Corp.
  819. 8100 N. McCormick Blvd.
  820. Skokie, IL 60076-2999
  821.  
  822. Phone: 847-342-6898
  823. EMail: pcalhoun@usr.com
  824.  
  825. Allan C. Rubens
  826. Merit Network, Inc.
  827. 4251 Plymouth Rd.
  828. Ann Arbor, MI 48105-2785
  829.  
  830. Phone: 313-647-0417
  831. EMail: acr@merit.edu
  832.  
  833. Bernard Aboba
  834. Microsoft Corporation
  835. One Microsoft Way
  836. Redmond, WA 98052
  837.  
  838. Phone: 206-936-6605
  839. EMail: bernarda@microsoft.com
  840.  
  841.  
  842.  
  843.  
  844.  
  845.  
  846.  
  847.  
  848.  
  849.  
  850.  
  851.  
  852. Calhoun, Rubens & Aboba                                      [Page 13]
  853.  
  854.  
  855.