One document matched: draft-ietf-roamops-sec-00.txt

ROAMOPS Working Group                             Yuan John Jiang
Internet Draft                                                MCI
expires in six months                                October 1997

    Secure Radius Server Operation Guidelines for Dial Roaming
                 <draft-ietf-roamops-sec-00.txt >

Status of this Memo

  This document is an Internet-Draft.  Internet-Drafts are
  working documents of the Internet Engineering Task Force
  (IETF), its areas, and its working groups.  Note that other
  groups may also distribute working 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 material or to cite them other
  than as work in progress.

  To learn the current status of any Internet-Draft, please check
  the id-abstracts.txt listing contained in the Internet-Drafts
  Shadow Directories on ds.internic.net (US East Coast),
  ic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
  munnari.oz.au (Pacific Rim).

  The distribution of this memo is unlimited. It is filed as
  <draft-ietf-roamops-sec-00.txt>, and expires in April, 1998.
  Please send comments to the author.

Abstract

  Authenticating and authorizing roaming dialup users requires
  messages to be exchanged among facilities managed by two or
  more service providers, and secure operation of the facilities
  is of vital importance.  This document provides guidelines for
  operating such facilities when using the Remote Authentication
  Dial In User Service (RADIUS) protocol and the companion
  accounting protocol for authentication and accounting message
  exchange. 1








  Y. J. Jiang                                                 [1]












                                                    October, 1997



1 Introduction

  Internet dial roaming is described in [1] and demonstrated in
  [2].  Such a service usually requires that user authentication
  messages be exchanged among facilities administrated by
  different service providers.

  It is common practice to use the RADIUS protocol as defined in
  [3] for authentication and the RADIUS accounting protocol [4]
  for accounting message exchanges.  The protocols have a few
  weaknesses, which make roaming services particularly prone to
  security risks.

  This document does not intend to invent new schemes to overcome
  difficulties in secure operation but rather defines good
  practices within the limits of the current RADIUS framework.

1.1 Terminology

  This document frequently uses the following terms:

  Network Access Server (NAS)
    A network device that users dial up in order to obtain access
    to the network.

  RADIUS server
    A network component that receives RADIUS or Accounting
    Request packets.

  Home RADIUS server
    A Radius server that verifies a dialup user's identity.

  Proxy RADIUS server
    An intermediate Radius server between a NAS and a home Radius
    server used to relay and modify RADIUS or Accounting packets.
    A proxy server acts as a RADIUS client to the downstream
    Radius server and a server to an upstream server or a NAS.

1.2 Specification of Requirements

  In this document, several words are used to signify the
  requirements of the specification.  These words are often
  capitalized.

  MUST This word, or the adjective "required", means that the
    definition is an absolute requirement of the specification.



  Y. J. Jiang                                                 [2]












                                                    October, 1997



  MUST NOT This phrase means that the definition 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
    this item, but the full implications must be understood and
    carefully weighed before choosing a different course.

  MAY This word, or the adjective "optional", means that this
    item is one of an allowed set of alternatives.  An
    implementation which does not include this option MUST be
    prepared to interoperate with another implementation which
    does include the option.

1.3 RADIUS and dial roaming

  The primitive use of RADIUS protocol is for the authentication
  message exchange between a NAS receiving a user's call and a
  Radius authentication server maintaining the user database.
        RADIUS
  NAS <---------> RADIUS Server
  Typically, the NAS sends the server an Access-Request packet
  containing the user's username, authentication data and
  requested service and resource information, and the server
  replies with an Access-Reject or Access-Accept packet
  containing the rejection reason or the information on the
  service and resources authorized for the user.  The accounting
  Request and response packets are exchanged in a similar
  fashion.

  In dial roaming, to authenticate a user, message exchanges are
  not limited to one client and one server.  At least one proxy
  Radius server is involved between the NAS and the home Radius
  authentication server containing the user database.
        RADIUS                       RADIUS
  NAS <-------> Proxy RADIUS Server <-------> Home RADIUS Server
  More complicated operation models described in [2] involve two
  or more cascading proxy Radius servers or one RADIUS packet
  branched out to two or more Radius servers. For roaming user
  authentication, authorization and accounting, the Radius
  facilities -- the NASs and the proxy and home Radius servers --
  are managed by different service providers, and the RADIUS
  packets are transported over the public network beyond the
  control of the NAS and the home Radius server operators.
  Security risks increase because authentication and accounting




  Y. J. Jiang                                                 [3]












                                                    October, 1997



  packets have much higher chance than in a single operator
  environment to be captured, modified and injected by
  adversaries.

2 Security weaknesses in RADIUS protocol

2.1 Packet integrity and sender identity checking

  A Radius client and server maintain between them a shared
  secret.  If a server can derive from a received packet that the
  sender has the correct IP address and knows the shared secret,
  it is convinced of the client's identity.  The same scheme
  applies when a client checks a server's identity from a
  response packet received.

  RADIUS protocol and the accounting protocol frequently use an
  Authenticator field in combination with the shared secret to
  check packet integrity and sender identity.  For example, the
  Authenticator is the MD5 digest of
   Accounting-Request Code + Identifier + zero-filled Authenticator
   + Attributes + Shared Secret
  for an Accounting-Request packet or
   Response Code + Identifier + Request Authenticator + Attributes
   + Shared Secret
  for an Access or Accounting Response packet.

  RADIUS Access-Request packets, however, contain no packet
  integrity checking fields, nor have they sender identity
  checking fields unless User-Password attributes are present.
  An Authenticator field in an Access-Request packet is a random
  number and does not offer any packet integrity checking.  A
  User-Password attribute is the plain-text user password encoded
  with the MD5 digest of the octet stream consisting the shared
  secret and the Authenticator.

  A home Radius server has the correct user password in its user
  database to compare with the one decoded from the User-Password
  attribute.  When the comparison is successful, it can be sure
  of the NAS's identity; otherwise, it cannot tell whether the
  sender does not know the shared secret or does not have the
  correct user password.  Further, the User-Password attribute
  does not help at all a proxy server, which does not have the
  correct user password at hand, to check the packet sender's
  identity.



  Y. J. Jiang                                                 [4]












                                                    October, 1997



2.2 Hop-by-hop vs. end-to-end security

  In dial roaming, the packet sender identity and message
  integrity checking mechanism used between a client and server
  described above is carried over to the checking between the
  RADIUS components in every hop.  This is considered an
  advantage.  For example, an intermediate hop may provide some
  user services, which require modification of the attributes in
  the Access-Request and Access-Accept packets to reflect the
  resources requested and the resources authorized according to
  the service specifics.

  On the other hand, for user authentication, this hop-by-hop
  model is considered to be less secure than full end-to-end
  authentication if the intermediate hops cannot be fully
  trusted.  This is the case when an adversary can pose as a
  legitimate RADIUS component in the chain of packet passage, or
  when some of the intermediate proxy servers may alter the
  packet content beyond their business contract or legal
  capacities or even inject fraudulent packets in the passage.

  The hop-by-hop vs. end-to-end dilemma arises from the facts
  that RADIUS protocol is used not only for authentication but
  also for resource authorization purposes and that the
  intermediate Radius servers in a proxy chain are often needed
  to play roles in resource authorization rather than simply for
  packet relay.

  The attributes a Radius server is interested in depends on the
  role it plays.  However, a Radius server may play more than one
  role, and more than one server may be interested in the same
  attributes. Framed-IP-Address attribute in an Access-Accept
  packet, for example, is assigned sometimes by the NAS
  operator's Radius server and sometimes by the home Radius
  server.

2.3 Data confidentiality

  RADIUS protocol and the companion accounting protocol have no
  attribute information hiding capability except on
  authentication credential attributes such as User-Password.
  The password hiding in CHAP-Password attribute is inherent from
  CHAP, but the password hiding in a User-Password attribute is
  limited considering the intermediate RADIUS components not
  involved in user authentication can decode the password.




  Y. J. Jiang                                                 [5]












                                                    October, 1997



  User password checking is usually the role of the home Radius
  server.  No intermediate Radius servers should have any
  business in the User-Password attribute, but unfortunately they
  all can decode and even edit the user password.

  The lack of data confidentiality leaves exposed
  - dialup users' usage information,
  - network operators' facility information, and
  - service providers' customer bases.
  It puts users' privacy and service providers and operators'
  trade secret at risk.

  It would be desirable if an attribute could be inspected only
  by the designated RADIUS facility.

2.4 Using IPsec

  Many have suggested using IPsec to overcome the security
  problems with RADIUS and the accounting protocols.  This may
  help in packet integrity and sender identity checking,
  preventing replay attacks and, to some extent, data
  confidentiality.  However, as a lower layer measure, IPsec
  cannot solve the hop-by-hop vs. end-to-end dilemma in the upper
  layer and prevent a proxy server from tampering with attributes
  beyond its intended scope.

2.5 Attribute level security

  The ultimate solution to the hop-by-hop vs. end-to-end dilemma
  and the data confidentiality problem lies with attribute level
  security, with which an attribute can be inspected and edited
  only by the specified Radius servers in the proxy chain.
  However, RADIUS, designed as a simple protocol, is not likely
  ever to be extended to include attribute level security.
  Without attribute level security, the length of a proxy chain
  and the complexity of a roaming relation are limited by trust,
  and proxy servers should not be used only for packet relay
  without any other benefit.

3 Security risks

  Because of the above RADIUS protocol weaknesses, the immediate
  risks in roaming user authentication are
  - theft of user passwords,





  Y. J. Jiang                                                 [6]












                                                    October, 1997



  - theft of services,
  - denial of services, and
  - fraudulent packet injection.

  For example, lack of Access-Request packet sender identity
  checking unless a User-Password attribute is used gives an
  adversary a chance to pose as a legitimate RADIUS client using
  IP spoofing techniques.  This adversary can take advantage of
  lack of message integrity and sender identity checking
  - to launch a dictionary attack and obtain a user's CHAP
  password,
  - to replay a captured Access-Request packet and exhaust the
  resources
    authorized to a user, or
  - to replay captured Access-Request packets and overload the
  Radius server.

4 Signature attribute

  An Internet Draft [5] has proposed adding a Signature attribute
  to overcome the security weakness in checking sender identity
  and content integrity of Access-Request packets.  The content
  of the attribute is an MD-5 [3] digest of the shared secret
  followed by the entire Access-Request packet, including the
  Code, ID, Length and Authenticator.  When the digest is
  calculated the signature string is filled with sixteen octets
  of zero.

  At this writing, a few NAS vendors have planned to implement
  this feature in their products.  In a roaming relation, the
  Signature attribute MUST be used in any Access-Request packet
  sent across administrative boundaries.  This attribute should
  be used even when the packet contains a User-Password
  attribute.

  A proxy Radius server must strip the Signature attribute, if
  present, in an Access-Request packet received from a NAS or an
  up-stream Radius server and must add its own Signature
  attribute to the packet when sending to the down-stream Radius
  server.  An Access-Request packet MUST not contain more than
  one Signature attribute.

5 Authenticator

  The Authenticator field in an Access-Request packet must be
  used strictly accordingly to [3].  Otherwise, intercepted



  Y. J. Jiang                                                 [7]












                                                    October, 1997



  Access-Request packets can be replayed by an adversary for
  denial of service attacks, and intercepted Access-Accept
  packets can be used for theft of services.

  The RADIUS protocol specification states:

     In Access-Request Packets, the Authenticator value is a 16
     octet random number, called the Request Authenticator.  The
     value SHOULD be unpredictable and unique over the lifetime
     of a secret (the password shared between the client and the
     RADIUS server), since repetition of a request value in
     conjunction with the same secret would permit an attacker to
     reply with a previously intercepted response.  Since it is
     expected that the same secret MAY be used to authenticate
     with servers in disparate geographic regions, the Request
     Authenticator field SHOULD exhibit global and temporal
     uniqueness.

     The Request Authenticator value in an Access-Request packet
     SHOULD also be unpredictable, lest an attacker trick a
     server into responding to a predicted future request, and
     then use the response to masquerade as that server to a
     future Access-Request.

  A proxy Radius server typically has many clients and with each
  maintains a different shared secret.  It is possible that more
  than one Accept-Request packet with the same Authenticator
  content may come from different clients but destined for the
  same down-stream Radius server.  Therefor, to maintain the
  uniqueness and unpredictable nature of the Authenticator, the
  proxy server MUST strip the Authenticator from a received
  Access-Request packet and insert its own when forwarding the
  packet to the downstream Radius server.

  This Authenticator alteration may not be compatible with the
  practice of many NASs when authenticating using Challenge
  Handshake Authentication Protocol (CHAP).  These NASs fill the
  Authenticator with the 16-byte CHAP challenges.  A Radius
  server identifies this situation by the presence of a
  CHAP-Password attribute in a received Access-Request packet and
  the absence a CHAP-Challenge attribute.  In this case, the
  proxy Radius server MUST copy the Authenticator to a
  CHAP-Challenge attribute and insert its own Authenticator
  before forwarding the packet to the down-stream Radius server.





  Y. J. Jiang                                                 [8]












                                                    October, 1997



6 User-Password attribute

  In a proxy chain of a roaming authentication, any intermediate
  hop can decode the user password contained in a User-Password
  attribute. The revelation or editing of the user password by
  intermediate parties imposes security risks.  Therefore, this
  User-Password attribute MAY not be used in roaming user
  authentication unless a one-time user password system is used.
  This usually means that PAP may not be used.

7 Acknowledgements

  The author wishes to thank Cesar Cortes of MCI, Sara Lee of
  Concert and Jill Hacker for insightful comments.

8 References

  [1] B. Aboba, G. Zorn.  "Dialing Roaming Requirements."
  Internet draft (work in progress),
  draft-ietf-roamops-roamreq-05.txt, Microsoft, July, 1997.

  [2] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang.  "Review of
  Roaming Implementations."  RFC 2194, Microsoft, Aimnet, i-Pass
  Alliance, Asiainfo, Merit, September, 1997.

  [3] C. Rigney, A. Rubens, W. Simpson, S. Willens.  "Remote
  Authenti-cation Dial In User Service (RADIUS)."  RFC 2138,
  Livingston, Merit, Daydreamer, April, 1997.

  [4] C. Rigney.  "RADIUS Accounting."  RFC 2139, Livingston,
  April, 1997.

  [5] C. Rigney, W. Willats.  "RADIUS Extensions."  Internet
  draft (work in progress), draft-ietf-radius-ext-00.txt,
  Livingston, January, 1997. 9

  Author's Addresse

     Yuan John Jiang
     MCI Internet Engineering
     2100 Reston Parkway
     Reston, VA 20191

     Phone: 703-715-7480
     EMail: yjj@mci.net




  Y. J. Jiang                                                 [9]