[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08

INTERNET DRAFT                                            Pat R. Calhoun
Category: Standards Track                          Sun Microsystems, Inc.
Title: draft-calhoun-diameter-authent-01.txt
Date: March 1998



                                       DIAMETER
                            User Authentication Extensions
                       <draft-calhoun-diameter-authent-01.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.
   Internet-Drafts  may  be  updated,  replaced,  or  obsoleted  by other
   documents at any time.  It is not appropriate to  use  Internet-Drafts
   as  reference  material  or  to  cite  them  other than as a ``working
   draft'' or ``work in progress.''

   To learn the current status of any Internet-Draft,  please  check  the
   1id-abstracts.txt  listing  contained  in  the  Internet-Drafts Shadow
   Directories on ds.internic.net,  nic.nordu.net,  ftp.nisc.sri.com,  or
   munnari.oz.au.

Abstract

   DIAMETER is a management protocol used between Network Access  Servers
   and  DIAMETER Servers for authentication, authorization, accounting of
   dial-up users. A considerable amount of effort was put into the design
   of  this  protocol to ensure that an implementation could support both
   DIAMETER and RADIUS at the same time.

   This document details the RADIUS authentication messages and how  they
   may be used with the DIAMETER protocol.


Table of Contents

      1.0  Introduction
      1.1  Specification of Requirements
      2.0  Command Name and Command Code
      3.0  Command Meanings
      3.1  Domain-Discovery-Request
      3.2  Domain-Discovery-Response


Calhoun                  expires September 1998                  [Page 1]


INTERNET DRAFT                                                 March 1998


      3.3  Authentication-Request
      3.4  Authentication-Success
      3.5  Authentication-Failure
      4.0  Protocol Definition
      4.1  RADIUS Proxies
      4.2  DIAMETER Proxies
      4.2  Domain Discovery
      5.0  References
      6.0  Authors' Addresses


1.0  Introduction

    This  document  specifies  extensions  to  the   original   RADIUS[1]
    authentication messages.

    There exists a scenario where services providers wish  to  proxy  the
    authentication  of  a user to a remote DIAMETER Server, yet wishes to
    perform the authorization for the said user.

    There are also  many  instances  where  a  NAS  may  wish  to  simply
    authenticate  a  user  and not have any authorization assigned to the
    request.


1.1  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.

    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 ignore 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.




Calhoun                  expires September 1998                  [Page 2]


INTERNET DRAFT                                                 March 1998


2.0  Command Name and Command Code

    Command Name: Domain-Discovery-Request
    Command Code: 6

    Command Name: Domain-Discovery-Response
    Command Code: 7

    Command Name: Authentication-Request
    Command Code: 8

    Command Name: Authentication-Success
    Command Code: 9

    Command Name: Authentication-Failure
    Command Code: 10


3.0  Command Meanings

3.1  Domain-Discovery-Request

    Description

      The Domain-Discovery-Request message is used by a  DIAMETER  device
      wishing   to   get   contact  information  about  a  domain's  home
      authentication  server  as  well  as  to  receive  password  policy
      information.  This  message MUST contain the User-Name attribute in
      order to pass along the user's domain information.

      A summary of the Domain-Discovery-Request packet  format  is  shown
      below. The fields are transmitted from left to right.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Attribute Type         |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |         Command Type          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Code

      256     DIAMETER Command


    Length

      The length of this attribute MUST be 7.



Calhoun                  expires September 1998                  [Page 3]


INTERNET DRAFT                                                 March 1998


    Flags

      The flag field MUST have bit 1 (Mandatory Support) set.


    Command Type

      The Command Type field MUST be set to 6 (Domain-Discovery-Request).


3.2  Domain-Discovery-Response

    Description

      The Domain-Discovery-Response message is sent in  response  to  the
      Domain-Discovery-Request    message    by    the    domain's   Home
      authentication server. The message MUST contain  either  the  X509-
      Certificate  or  the X509-Certificate-URL attribute and MAY contain
      the Password-Policy attribute.

      A summary of the Domain-Discovery-Response packet format  is  shown
      below. The fields are transmitted from left to right.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Attribute Type         |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |         Command Type          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Code

      256     DIAMETER Command


    Length

      The length of this attribute MUST be 7.


    Flags

      The flag field MUST have bit 1 (Mandatory Support) set.


    Command Type

      The  Command  Type  field  MUST  be  set  to  7  (Domain-Discovery-
      Response).


Calhoun                  expires September 1998                  [Page 4]


INTERNET DRAFT                                                 March 1998


3.3  Authentication-Request

    Description

      The Authentication-Request message is  used  in  order  to  request
      authentication  and  authorization for a given user. Note that this
      command does not require  the  presence  of  a  user  name  as  the
      credentials  used  MAY  be  a  telephone  number  (i.e.  DNIS, ANI)
      instead.

      Note that the flag field MAY be used in this command  in  order  to
      indicate  that  either Authentication-Only or Authorization-Only is
      required for the request. If the Authentication-Only bit is set the
      response  MUST  NOT include any authorization information. At least
      one of the Authenticate/Authorize flag bits MUST be set.

      A summary of the  Authentication-Request  packet  format  is  shown
      below. The fields are transmitted from left to right.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Attribute Type         |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |         Command Type          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Code

      256     DIAMETER Command


    Length

      The length of this attribute MUST be 7.


    Flags

      The flag  field  MUST  have  bit  1  (Mandatory  Support)  set.  In
      addition,  the  following  bits  may  be  used (note these bits are
      mutually exclusive):

          bit 3 - Authenticate-Only
          bit 4 - Authorize-Only


    Command Type

      The Command Type field MUST be set to 8 (Authentication-Request).


Calhoun                  expires September 1998                  [Page 5]


INTERNET DRAFT                                                 March 1998


3.4  Authentication-Success

    Description

      The Authentication-Success message is used  in  order  to  indicate
      that   Authentication   (or   authorization)   was  successful.  If
      authorization was requested a list of AVPs with  the  authorization
      information MUST be attached to the message (see [1]).

      Note that the flag field MUST be set to the  same  value  that  was
      found in the Authentication-Request message.

      A summary of the Access-Request packet format is shown  below.  The
      fields are transmitted from left to right.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Attribute Type         |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |         Command Type          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Code

      256     DIAMETER Command


    Length

      The length of this attribute MUST be 7.


    Flags

      following  bits  may  be  used  (note  these  bits   are   mutually
      exclusive):

          bit 3 - Authenticate-Only
          bit 4 - Authorize-Only


    Command Type

      The Command Type field MUST be set to 9 (Authentication-Success).


3.5  Authentication-Failure

    Description


Calhoun                  expires September 1998                  [Page 6]


INTERNET DRAFT                                                 March 1998


      The Authentication-Failure message is used  in  order  to  indicate
      that  Authentication  (or authorization) was unsuccessful. The list
      of AVPs that may be attached to this message can be found in [1].

      Note that the flag field MUST be set to the  same  value  that  was
      found in the Authentication-Request message.

      A summary of the Access-Request packet format is shown  below.  The
      fields are transmitted from left to right.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |        Attribute Type         |            Length             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     Flags     |         Command Type          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Code

      256     DIAMETER Command


    Length

      The length of this attribute MUST be 7.


    Flags

      following  bits  may  be  used  (note  these  bits   are   mutually
      exclusive):

          bit 3 - Authenticate-Only
          bit 4 - Authorize-Only


    Command Type

      The Command Type field MUST be set to 10 (Authentication-Failure).


4.0  Protocol Definition

    This section will outline how the DIAMETER  Authentication  Extension
    can be used.

4.1  RADIUS Proxies

    In  today's  dial  up  networks  the  RADIUS  protocol  is  used   to


Calhoun                  expires September 1998                  [Page 7]


INTERNET DRAFT                                                 March 1998


    authentication, authorize and perform accounting for  dial-up  users.
    However,  it has become common practice to make use of RADIUS Servers
    known as proxies.

    The  use  of  proxies  has  become  widespread  especially  with  the
    popularity  of  Internet  Roaming[4].  In  this  example a user has a
    single user account with a local service  provider.  When  this  user
    roams  outside  of his ISPs service area, it is possible for the user
    to connect to another service provider (see [4] for more details).

    In this scenario, the new service provider (ISPB)  provides  internet
    access for the user through a NAS (NASB). ISPB owns an authentication
    server (RADB), which proxies the authentication request to the user's
    original provider's authentication server (RADA).

                (Access-Request)           (Access-Request)
      +------+       ----->       +------+      ------>       +------+
      |      |                    |      |                    |      |
      | NASB +--------------------+ RADB +--------------------+ RADA +
      |      |                    |      |                    |      |
      +------+       <-----       +------+      <------       +------+
                 (Access-Accept)            (Access-Accept)


    The example shown above NASB generates an authentication  request  on
    behalf of the dial-in user to the RADB Authentication server. In this
    case, the user's identity would include a domain identifier [3]  that
    would  enable  RADB  to  identify  the  authentication  server  (i.e.
    user@ISPA.com).

    The RADB server then forwards the request to RADA which authenticates
    the   user   based  on  information  found  within  the  request.  If
    successfully authentication the  RADA  server  returns  a  successful
    response   along   with   authorization  information.   If  the  user
    authentication fails RADA replies with a failed response.

    In the past this model has caused much  concern  over  it's  security
    implication.  The model is much worse in the model where there exists
    an intermediate provider  between  ISPB  and  ISPA  (say  ISPC).  The
    following diagram depicts such an example where RADB must forward any
    requests for RADA through RADC.

              (Accounting-Request)        (Accounting-Request)
      +------+       ----->       +------+      ------>       +------+
      |      |                    |      |                    |      |
      | RADB +--------------------+ RADC +--------------------+ RADA +
      |      |                    |      |                    |      |
      +------+       <-----       +------+      <------       +------+
              (Accounting-Response)       (Accounting-Response)



Calhoun                  expires September 1998                  [Page 8]


INTERNET DRAFT                                                 March 1998


    The problem with the above scenario is that complete trust is  placed
    in  RADC  (and  hence  ISPC)  since  it  is very simple to modify any
    attributes found within the request  or  the  response.  The  example
    shows  an accounting request sent from RADB to RADA through RADC. The
    following is a list of a few attacks which  can  be  generated  by  a
    malicious proxy:

      -    Generating    Accounting    Records    by    replaying     old
      authentication/accounting  records.  In  this  example  it  is very
      simple for RADC to simple retain old packets and replay then  at  a
      later  date.  This will cause RADA to "pay" for services which were
      never rendered.

      - Modify Attributes within the request or response.  In  this  case
      RADC  can  modify  attributes, such as the length of the call, that
      would fool RADA into believing the call was longer than in reality.

      - Stealing PAP Passwords is another problem with  today's  proxies.
      In  the  current  model  PAP passwords are encrypted using a shared
      secret which is shared between each hop in the proxy chain. In this
      case each hop has the opportunity to decrypt, and possibly save for
      future use, the user's password.  fool RADA into believing that

    Given the problems identified above with the current proxy  model  it
    is  necessary to create a mechanism which allows for non-repudiation,
    end-to-end data integrity as well as end-to-end encryption. Given the
    current  encryption technology this can only be achieved with the use
    of asymetric encryption and digital signatures.


4.2  DIAMETER Proxies

    The DIAMETER protocol also the use of proxies in order  to  keep  the
    existing  arrangements  while  migrating  from  RADIUS  to  DIAMETER.
    However since DIAMETER makes use of asymetric encryption and  digital
    signatures it solves many of the problems shown above.

                (Access-Request)           (Access-Request)
      +------+       ----->       +------+      ------>       +------+
      |      |                    |      |                    |      |
      | NASB +--------------------+ DIA2 +--------------------+ DIA1 +
      |      |                    |      |                    |      |
      +------+       <-----       +------+      <------       +------+
                 (Access-Accept)            (Access-Accept)

    In this example NASB  generates  an  Authentication-Request  that  is
    forwarded  to  DIA2.  The  Authentication-Request  contains a digital
    signature AVP which "protects" all mandatory (or  non-editable)  AVPs
    within the request. All AVPs which may be modified, or removed appear
    after the digital signature AVP. Once DIA2 receives the  request,  it


Calhoun                  expires September 1998                  [Page 9]


INTERNET DRAFT                                                 March 1998


    MAY authenticate the request to ensure that it was originated by NASB
    (verifying  the  signature  is not necessary if the link between NASB
    and DIA2 is secured using IPSEC).

    The DIA2 Server may then add  new  attributes  to  the  request.  All
    mandatory  AVPs  MUST  be present prior to the non mandatory AVPs and
    MUST be preceeded by a Digital Signature AVP  (using  DIA2's  private
    key).  Note  that  all non-mandatory AVPs added to the packet by NASB
    must appear after DIA2's digital signature AVP. The message  is  then
    forwarded towards the DIA1 server.

    Since all packets between NASB and DIA1 must flow through DIA2, it is
    not  possible  to  use  IPSEC between both hosts. Therefore DIA1 MUST
    validate NASB's digital signature AVP. However it is not necessary to
    validate  DIA2's  digital signature if the link between DIA2 and DIA1
    is secured using IPSEC.

    This mechanism now provides a method for DIA1 to prove that NASB  was
    the  initiator  of  the  request  (note that DIAMETER also includes a
    timestap to prevent replay attacks). It also  provides  a  method  of
    ensuring  that RADB cannot modify any "non-editable" attributes (such
    as length of call, etc).

    In addition,  this  same  mechanism  can  be  used  for  end  to  end
    encryption of AVPs. In the case where NASB needs to encrypt an AVP it
    is done using asymetric encryption  using  DIA1's  public  key.  This
    ensures that only RADA can decrypt the AVP.

    An attack has  been  identified  in  this  proposal  which  allows  a
    malicous man in the middle attack as shown in the following diagram.

           (Access-Request)  (Access-Request)  (Access-Request)
      +------+  ----->  +------+  ----->  +------+  ----->  +------+
      |      |          |      |          |      |          |      |
      | NASB +----------+ DIA2 +----------+ DIA3 +----------+ DIA1 +
      |      |          |      |          |      |          |      |
      +------+  <-----  +------+  <-----  +------+  <-----  +------+
           (Access-Accept)   (Access-Accept)   (Access-Accept)

    In this example, DIA3 traps packets generated from DIA2 towards DIA1,
    removes  the  AVPs added by DIA2 and inserts its own AVPs (posibly by
    trying to convince DIA1 to pay DIA3 for the  services).  This  attack
    can  be prevented by supporting a new Next-Hop AVP. In this case when
    NASB prepares a request it inserts a non-editable Next-Hop AVP  which
    contains  DIA2's  identitity. DIA2 also adds a Next-Hop AVP with DIA1
    as the next hop.

    This mechanism ensures that a man in  the  middle  cannot  alter  the
    packet by overriding the previous hop's additions and signature. DIA1
    could easily validate the packet's path with the use of the  Next-Hop


Calhoun                 expires September 1998                  [Page 10]


INTERNET DRAFT                                                 March 1998


    AVPs.


4.3  Domain Discovery

    The Domain Discovery message set is very useful  in  determining  the
    Home  authentication server, the password policies for the domain, as
    a  mechanism  to  retrieve  a  certificate  (or  a   pointer   to   a
    certificate).

    The following example shows a case where DIA1  needs  to  communicate
    with  DIA3. In this example it is necessary to use DIA2 as a proxy in
    order for both ISPs to communicate. Although this MAY  be  desireable
    in  some  business  models, there are cases where it is beneficial to
    remove  the  proxy  altogether  and  allow  both  DIA3  and  DIA2  to
    communicate in a secure fashion.

                  (DD-Request)               (DD-Request)
      +------+       ----->       +------+      ------>       +------+
      |      |                    |      |                    |      |
      | DIA1 +--------------------+ DIA2 +--------------------+ DIA3 +
      |      |                    |      |                    |      |
      +------+       <-----       +------+      <------       +------+
                  (DD-Response)              (DD-Response)

    The way the Domain Discovery works is that prior to  sending  out  an
    authentication  request  DIA1  would issue a Domain Discovery message
    towards DIA2. This message is protected with the digital signature as
    well as the Next-Hop AVP. DIA2 would then forward the request to DIA3
    including the Next-Hop and the digital signature AVP.

    When DIA3 receives the request, it MUST save the certificate (or  the
    pointer  to  the  certificate)  and  respond back including the local
    password policy, DIA3's certificate, it's contact  information  (i.e.
    IP address) and protect the response with the digital signature.

    Note that in all cases the TimeStamp AVP is also present to ensure no
    reply packets are accepted.

    When DIA2 receives the packet, it must add the Next-Hop AVP  as  well
    as  the  digital  signature AVP. When DIA1 receives the packet is now
    knows a direct route to  communicate  with  DIA3  since  the  contact
    information  is  present in the response. The fact that both DIA1 and
    DIA3 can now communicate directly allows both peers to use  IPSEC  to
    protect  the  message exchange (note that it MAY be desirable to also
    use the digital signature in order to keep  the  information  in  the
    DIAMETER logs).

                                 (Authentication-Request)
                        +------+       ----->       +------+


Calhoun                 expires September 1998                  [Page 11]


INTERNET DRAFT                                                 March 1998


                        |      |                    |      |
                        | DIA1 +--------------------+ DIA3 +
                        |      |                    |      |
                        +------+       <-----       +------+
                                (Authentication-Response)

     In addition, the password policy is also present which can  indicate
     whether DIA3 is willing to accept CHAP, PAP or EAP authentication.

     Note that the  Domain-Request/Response  MAY  include  the  Features-
     Supported AVPs.


5.0  References

    [1] Rigney, et alia, "RADIUS", RFC-2058, Livingston, January 1997
    [2] P. R. Calhoun, A. Rubens, "DIAMETER Base Protocol",
        draft-calhoun-diameter-00.txt, February 1998.
    [3] B. Aboba.  "The Network Access Identifier." Internet-Draft,
        August 1997.
    [4] Aboba, Zorn, "Dialup Roaming Requirements", Internet-Draft,
        July 1997.


6.0  Authors' Addresses

   Questions about this memo can be directed to:

      Pat R. Calhoun
      Technology Development
      Sun Microsystems, Inc.
      15 Network Circle
      Menlo Park, California, 94025
      USA

       Phone:  1-847-548-9587
         Fax:  1-650-786-6445
      E-mail:  pcalhoun@toast.net














Calhoun                 expires September 1998                  [Page 12]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/