INTERNET DRAFT                                   Pat R. Calhoun (editor)
Category: Informational                           Sun Microsystems, Inc.
Title: draft-ietf-aaa-issues-01.txt                        Bernard Aboba
Date: October 2000                                             Microsoft
                                                            Erik Guttman
                                                  Sun Microsystems, Inc.
                                                             Dave Mitton
                                                         Nortel Networks
                                                             Dave Nelson
                                                Enterasys Networks, Inc.
                                                   Juergen Schoenwaelder
                                       Technical University Braunschweig
                                                            Barney Wolff
                                                            Databus Inc.
                                                             Lixia Zhang
                                                                    UCLA


                         AAA Problem Statements



Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  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."

   The list of current Internet-Drafts can be accessed at:

      http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at:

      http://www.ietf.org/shadow.html.

   This document is an individual contribution for consideration by the
   AAA Working Group of the Internet Engineering Task Force.  Comments
   should be submitted to the diameter@diameter.org and aaa-wg@merit.edu
   mailing lists.




Calhoun et al.             expires April 2001                   [Page 1]


INTERNET DRAFT                                              October 2000


   Distribution of this memo is unlimited.

   Copyright   (C) The Internet Society 2000.  All Rights Reserved.


Abstract

   The AAA Evaluation Team's recommendation document raised some issues
   with the DIAMETER protocol. The AAA WG has created a design team to
   address these issues. This document is an attempt to describe the
   problems, which the WG can then concentrate on solving.


Table of Contents

      1.0  Introduction
            1.1  Requirements language
      2.0  Error Codes and Messages
            2.1  Error Messages Action Item List
      3.0  Accounting
            3.1  The Universal Approach
            3.2  Batch Accounting Issues
            3.3  Proxy Accounting Issues
            3.4  Semantic Issues
            3.5  Accounting Message "Bloat" Issues
            3.6  Accounting Message Format Issues
            3.7  Accounting Action Item List
      4.0  IPv6 Support
      5.0  Transports
            5.1  Failover & Recovery Sending
                  5.1.1  Failover Action Item List
      6.0  Proxies
            6.1  Proxy Behavior
            6.2  State/Path Retention
            6.3  Proxy Action Item List
      7.0  RADIUS Compatibility
      8.0  End-to-End Security
            8.1 End-to-End Security Action Item List
      9.0  Data Model
            9.1  Separability of DIAMETER Header and Message
            9.2  Data Types supported in DIAMETER
            9.3  Formal notation for application specific data types
                  9.3.1 Goals for formal notation
                  9.3.2 How to evaluate proposals for formal data
                        type languages
            9.4  Data Model Action Item List
      10.0 SNMP Support (DIAMETER MIB)
            10.1 Configuration of Sensitive Parameters



Calhoun et al.             expires April 2001                   [Page 2]


INTERNET DRAFT                                              October 2000


            10.2 Modular MIB(s)
            10.3 Traps and Informs
            10.4 SNMP Action Item List
      11.0 Re-Authentication & Authorization
      12.0 Server/Resource Management State
      13.0 Access Rules and Filters
            13.1 Access Rules and Filters Action Item List
      14.0 AAA Server Discovery
            14.1 Server Discovery Action Item List
      15.0 Loop Detection
            15.1 Loop Detection Action Item List
      16.0 IANA Considerations
      17.0 Security Considerations
      18.0 Acknowledgments
      19.0 References
      20.0 Authors' Addresses
      21.0 Full Copyright Statement


































Calhoun et al.             expires April 2001                   [Page 3]


INTERNET DRAFT                                              October 2000


1.0  Introduction

   The AAA Evaluation Team's recommentation document raised some issues
   with the DIAMETER protocol. The AAA WG has created a design team to
   address these issues. This document is an attempt to describe the
   problems, which the WG can then concentrate on solving.


2.0  Error Codes and Messages

   Given the extensibility nature of the DIAMETER protocol, future
   extensions will most likely need to allocate error codes to handle
   error conditions specific to the extension. This extensibility leads
   to an interoperability problem with implementations that do not
   support new extensions, since it becomes difficult to recognize how
   the error should be treated.

   The HTTP protocol has solved this problem by creating classes of
   errors.  Implementations only need to understand the error class in
   order to properly process the error code.

   One of the major issues with RADIUS [11] was the lack of error
   messages.  In RADIUS there was no way for the Accounting server to
   indicate conditions such as "too busy" or "out of disk space", so the
   only choice for an Accounting server experiencing difficulties is to
   not respond to an Accounting-Request, thereby causing re-
   transmissions that could exacerbate the problem. In addition, since
   there is no status message equivalent of "OK" or "Processing" in
   RADIUS there is no way for an accounting server to explicitly
   indicate that an accounting record has been written to stable
   storage. These issues preclude interpretation of a RADIUS
   Accounting-Response as an application-layer ACK.

   In addition to addressing these problems, DIAMETER also needs to
   define the interaction of error messages and security. For example,
   allowing error messages from an intermediate node to affect end-to-
   end communications may enable denial of service attacks.


2.1 Error Messages Action Item List

   The action items identified in this section are summarized as
   follows:

      1.) Define how the DIAMETER protocol could represent classes of
          errors.
      2.) Investigate how intermediate proxies inserting error codes in
          DIAMETER messages breaks end-to-end security, and find a



Calhoun et al.             expires April 2001                   [Page 4]


INTERNET DRAFT                                              October 2000


          solution.
      3.) Determine whether error messages should be used, or whether
          error codes are sufficient.
      4.) Ensure that the error codes defined have the necessary
          richness required for servers to return specific error
          conditions (e.g. out of disk space), which should cause the
          NAS (or downstream proxy) to try another accounting server.


3.0  Accounting

3.1 The Universal Approach

   One problem with the current Diameter Accounting draft [6] is that
   accounting is handled in a single protocol extension document.  The
   features of accounting include support for distinct environments,
   such as roaming, that may not be needed in other applications. It may
   be useful to consider accounting subsets for each of the supported
   application areas.


3.2 Batch Accounting Issues

   Section 1.2 of the Diameter Accounting draft [6] says "Each
   Accounting-Delivery-Max-Batch / Accounting-Delivery-Max-Delay AVP
   pair with different values forms one pool of accounting data in the
   Diameter node acting as a client." It seems that some more explicit
   and restricted form of pool creation may be desirable given the
   potentially large number of possible different "value pairs" for
   these AVPs.

   It has been suggested by some that FTP is a more appropriate protocol
   for batch accounting, depending of course, on what the ultimate batch
   size might be.


3.3 Proxy Accounting Issues

   Sections 1.3, 1.6 and 2.2 of the Diameter Accounting draft [6] deal
   with how accounting messages are handled for routing or broker proxy
   applications. The producer of a co-mingled-destination Accounting-
   Request record (e.g. a NAS) is required to handle a series of partial
   Accounting-Answer records from various home Accounting Servers. It
   would appear to be desirable for proxies to handle this extra work
   and complexity on behalf of the Diameter client.  Complexity arises
   out of partially acknowledged accounting data, potentially requiring
   the Diameter client to distinguish and communicate with individual
   home Accounting Servers that it would otherwise have no knowledge of.



Calhoun et al.             expires April 2001                   [Page 5]


INTERNET DRAFT                                              October 2000


   The issues of multi-party trust, counter-signatures and distributed
   non- repudiation capabilities are not as clearly explained in the
   draft as they might be. This is a complex area, and perhaps one in
   which accounting extensions specific to broker proxy operations might
   be warranted.


3.4 Semantic Issues

   The semantics of a successful Accounting-Answer message need to be
   further defined. Does this mean that the corresponding accounting
   data has been reliably written to stable storage (to disk, for
   example) at the ultimate destination (the home Accounting Server, for
   example)? Should there be error codes to indicate certain classes of
   failure, such as "out of disk space"? It might well be that the retry
   policy for a "no space" error would be different from that of a
   transient network outage.

   The use of the Accounting-Delivery-Max-Batch AVP should be clarified
   in the case of proxy chains. Will this AVP be modified by each proxy
   in the chain? How else would the aggregation of accounting data for
   multiple destinations be handled? The draft implies that the ultimate
   destination is uniquely and unambiguously defined by the NAI. Is this
   always the case?

   The use of the Accounting-State AVP and Accounting-Status-Ind AVP
   should be clarified in the case of proxy chains. Do proxies send
   these messages both upstream and downstream? Do all Diameter peers
   send them (e.g. Servers to NASes)? Are both AVPS really required?


3.5 Accounting Message "Bloat" Issues

   Accounting-Answer messages include the same ADIF-Record AVPs as were
   contained in the Accounting-Request messages, often with additional
   signatures. This is clearly to obtain distributed non-repudiation in
   proxy applications, especially brokering environments. This does lead
   to SNMP-style response "bloat" however, and it is not needed in all
   environments.


3.6 Accounting Message Format Issues

   The Diameter Accounting draft indicates that ADIF [15] is the only
   supported data format for accounting. There has been some indication
   that an applicability statement may be required for how ADIF is used
   within Diameter.




Calhoun et al.             expires April 2001                   [Page 6]


INTERNET DRAFT                                              October 2000


3.7 Accounting Action Item List

   The action items identified in this section are summarized as
   follows:

      1.) Investigate feature-specific subsets of the Diameter
          Accounting protocol, to mirror the Diameter Extension drafts
          [2,4,5,6,8].
      2.) Evaluate recommendation for "pools" created by distinct
          Accounting-Delivery-Max-Batch / Accounting-Delivery-Max-Delay
          AVP pairs.
      3.) Consider definition of batch size, and time intervals for
          batch accounting, and the use of other protocols, such as FTP.
      4.) Reconsider partial packet ACKs of accounting responses via
          proxy chains.
      5.) Elaborate on  issues of multi-party trust, counter-signatures
          and distributed non- repudiation capabilities.
      6.) The semantics of a successful Accounting-Answer message need
          to be further defined.
      7.) The use of the Accounting-Delivery-Max-Batch AVP should be
          clarified in the case of proxy chains.
      8.) The use of the Accounting-State AVP and Accounting-Status-Ind
          AVP should be clarified in the case of proxy chains.   Are
          both AVPs really needed?
      9.) Address the accounting response message "bloat" issue.
     10.) An applicability statement may be required for how ADIF is
          used within Diameter.


4.0  IPv6 Support

   Compatibility with IPv6 requires both the ability for DIAMETER to be
   transported over IPv6, as well as the ability to carry attributes
   required to configure IPv6 network access. Since hosts requiring
   network access may be dual stack, and the AAA server may not know
   this a-priori, a AAA server may need to return both IPv4 and IPv6
   attributes and allow the NAS and host to decide which ones to use.

   A first pass at determining the IPv6 attributes required for dialup
   access is available at:  http://www.ietf.org/internet-drafts/draft-
   aboba-radius-ipv6-02.txt In order to come up with a list of IPv6
   attributes for DIAMETER, it is expected that a similar review will be
   needed for other types of network access.


5.0  Transports

   AAA protocols typically are application driven, which means that the



Calhoun et al.             expires April 2001                   [Page 7]


INTERNET DRAFT                                              October 2000


   time between requests is typically larger than the round-trip time
   (RTT). This results in interactions between AAA protocols and
   reliable transport mechanisms including Nagle algorithm, RTT
   estimation, delayed ACKs, congestion control, fast re-transmit and
   fast recovery.

   In addition, AAA systems frequently include proxies.  As a result,
   the implementation details of such proxies significantly impact end-
   to-end behavior. For example, a proxy not implementing "back
   pressure" can prevent end-to-end self-clocking even if the AAA
   protocol is running over a transport (such as TCP or SCTP) which
   supports congestion control.

   As a result of these issues, it is necessary to develop a detailed
   understanding of how DIAMETER will behave when run over transports
   such as UDP, TCP and SCTP in the presence of proxies.


5.1  Failover & Recovery Sending

   SCTP gives an indication of peer failure, but nothing in any DIAMETER
   or SCTP document the evaluator was able to find even mentions how or
   when to switch back to a primary server to which communication was
   lost.  After a failure, the state machines end in a CLOSED state and
   nothing seems to trigger exit from that state. It was not clear
   whether a server, on rebooting, would initiate an SCTP connection to
   all its configured clients.  If not, and in any case when the
   communication failure was in the network rather than in the server,
   the client must itself, after some interval, attempt to re-establish
   communication.  But no such guidance is given.


5.1.1 failover Action Item List

   The action items identified in this section are summarized as
   follows:

      1.) Add a clear statement of the need for application-level
          failure detection and failover.
      2.) Add a clear statement of the need for restart of the transport
          protocol by one side or the other, to detect recovery of the
          partner.
      3.) Evaluate whether the algorithms for 1 & 2 need to be commonly
          agreed, or can be left to implementors.  For example, is a
          fixed rate of restart attempts (say once per minute)
          acceptable?  Or must there be exponential backoff of this too?
          Is success of transport protocol establishment sufficient to
          indicate application availability, or must an application-



Calhoun et al.             expires April 2001                   [Page 8]


INTERNET DRAFT                                              October 2000


          level probe be sent?
      4.) If the algorithm needs to be universal, design & document it.


6.0  Proxies

6.1  Proxy Behavior

   There two known types of servers, redirect and proxies. The DIAMETER
   specification describes these types of servers as brokers and
   proxies. The use of the term broker is problematic, since this term
   is mostly business-driven, and not necessarily technical. The
   specification should make use of the terminology redirect servers and
   proxies, and defined the functionality of each type of server.


6.2  State/Path Retention

   The DIAMETER specification makes use of two different types of
   mechanism to determine the path of the messages; Proxy-State and
   Destination-NAI. The former mechanism is based on the RADIUS
   protocol, while the latter was added to allow the reverse path the be
   different from the forwarding path. However, very little interest has
   been shown for the latter feature.

   In the RADIUS protocol, each RADIUS proxy MUST remove any existing
   Proxy-State attribute, and replace it with a new version. The Proxy-
   State attribute can contain state information that is generally
   useful to the sending server.  This requires that each proxy maintain
   the source of the message, in order to forward the response back to
   the same peer.

   The SIP RFC supports this functionality through its Via header field,
   which allows intermediate nodes to add their information to the
   message. This effectively builds a "source-route" of the message, and
   ensures that the reverse path is the same as the forwarding path. A
   Via-like AVP could also be used to encode state information, which
   would be used in the reverse (response) message.

   There are instances where a server would not wish to disclose the
   original server (or set of servers) of a message. This server should
   be allowed to remove the necessary portion of the Via-like AVP, and
   replace it with its own.  This would ensure that it would receive the
   corresponding response, and add the list of Via-like AVPs that had
   been truncated.


6.3 Proxy Action Item List



Calhoun et al.             expires April 2001                   [Page 9]


INTERNET DRAFT                                              October 2000


   The action items identified in this section are summarized as
   follows:

      1.) Properly define the terms proxy, broker, redirect server,
          transparent and non-transparent proxy in the DIAMETER
          specifications, and how each type of device should function.
      2.) Investigate whether the current Proxy-State and Destination-
          NAI AVPs provide the functionality required. Determine whether
          a SIP-like approach would be more advantageous. The SIP-like
          approach should allow for state information to also be encoded
          within the AVP.
      3.) If a SIP-like approach is used, investigate how end-to-end
          security is affected by entities adding their local
          information to messages.


7.0  RADIUS Compatibility

   RADIUS compatibility is a requirement for a new AAA protocol, as to
   be able to transition existing RADIUS environments to the new
   infrastructure over time.  It is clear that there will be features of
   the new protocol that will not be completely expressible in RADIUS.
   Those features should not be used in such a configuration, but all
   attempts should be made to design the protocol so that typical and
   common RADIUS operations of today can be easily supported by future
   AAA servers.

   Since AAA servers are typically implemented on host systems as
   software, they are more easily upgraded than NAS systems which often
   have embedded software constraints.  The likely situation in the
   future is that new AAA server systems will be deployed to provide new
   enhanced services, but also support legacy NAS servers which will
   either be eventually upgraded or replaced.

   The most desirable compatibility functions would be:

      a) A AAA server that can speak both RADIUS and Diameter, using a
         common system. (not just two separate servers)
      b) A AAA proxy server that can support a number of RADIUS speaking
         NASes, but communicates with a Diameter server or
         infrastructure.

   There should be a core correspondence between RADIUS messages and
   Diameter operations which is straight forward to implement and covers
   all typical RADIUS operations.  Returned attributes/AVPs that cannot
   be translated can be discarded if not mandatory.  Incompatible
   mandatory attributes MUST cause the operation to fail with an
   appropriate error return.  Solving this type of problem would have to



Calhoun et al.             expires April 2001                  [Page 10]


INTERNET DRAFT                                              October 2000


   be done by reconfiguring the gateway or the user return profile.  It
   may be possible (but not mandatory) that the gateway implements
   configurable translation rules for vendor or site specific features.
   It may also be possible that the server gets hints from the gateway
   about RADIUS translation, and knows not to return problem attributes.

   It is NOT a goal to provide the ability to gateway all new Diameter
   functions into RADIUS messages.  Particularly features such as new
   Vendor specific attributes, or security encodings cannot be expected
   to be supported.  Peer-to-peer features have no standard equivalents.


8.0  End-to-End Security

   The existing DIAMETER protocol provides security between the NAS (or
   Mobility Agent) and the Home DIAMETER server through the use of the
   Cryptographic Message Syntax (CMS) protocol. Typically, this security
   is used to detect fraudulent DIAMETER proxies, which could attempt to
   modify critical data within messages (e.g. session lifetime). There
   has been concern that the use of CMS may be too processor intensive,
   given that it makes exclusive use of public cryptography.

   Although the DIAMETER protocol does mention that in many cases, CMS
   would not be invoked by the NAS itself, but rather by the first hop
   DIAMETER, it is possible that this point needs to be strengthened.
   Furthermore, there is still concern that public key crypto on the
   servers may also be too intensive, and not always necessary.

   One possible solution is to look at the new work underway in the
   S/MIME group, which is defining support for symmetric key transforms
   within CMS (e.g.  draft-ietf-smime-symkeydist-01.txt). This would
   require an additional round trip to exchange the keys, but this would
   only be done when keys are not available. Another possible solution
   is to look at another cryptographic protocol.


8.1 End-to-End Security Action Item List

   The action items identified in this section are summarized as
   follows:

      1.) Discuss and justify the threat model under which NAS (or
          remote ISP) to home-server security is any improvement over
          hop-by-hop.
      2.) Stop the misuse of "end-to-end" to mean "NAS-to-home-server".
      3.) Clarify the separate concerns of disclosure of user
          information and cheating on billable accounting attributes.
          Which is the real concern?  Does one solution work for both?



Calhoun et al.             expires April 2001                  [Page 11]


INTERNET DRAFT                                              October 2000


      4.) Coordinate work on establishing a shared symmetric key with
          the server-discovery work.


9.0 Data Model

9.1 Separability of DIAMETER Header and Message

   The current DIAMETER protocol specification does not distinguish
   between the base protocol (with its set of base data types) and the
   application specific commands and the data structures communicated by
   the protocol. Experience with other protocols shows that it is
   valuable to logically separate the application specific data
   definitions carried by a protocol from the core services provided by
   a protocol.  It is often useful to be able to interpret a message
   using high-level functional parameters (for instance, in the header),
   even if the complete message can not be parsed (for example, if a
   particular AVP code is not supported by an AAA proxy).

   To this end, it may be useful to specify in the DIAMETER header
   whether a particular message is an Request, an Answer, a Query, a
   Response, or an Indication.


9.2 Data Types supported in DIAMETER

   The base data types in the current DIAMETER specification include
   Data, String, Address, Integer32, Integer64, Time and Complex. It is
   in general desirable to reduce the base types shipped by a protocol
   to a small orthogonal set which is sufficient to support the
   application specific data carried by the protocol, especially since
   it is difficult to add new base data types in the future.

   The Integer32 and Integer64 types are used for signed and sometimes
   for unsigned AVPs. It may make sense to introduce Unsigned32 and
   Unsigned64 as base types so avoid any ambiguities.

   The Time type is an Unsigned32 number reporting the number of seconds
   since January 1st 1900. There are several issues with this. First,
   the introduction of an Unsigned32 time implies that Time with its
   additional semantics as a base type is not needed anymore since the
   data definition can just define the special Time semantics on top of
   Unsigned32. Second, the 32 bit unsigned number will wrap in 2038 and
   it is desirable to prevent a "year 2038 problem" in DIAMETER, e.g. by
   starting the epoch at January 1st 2000 or by using the Unsigned64
   base type with the January 1st 1900 epoch.

   The Data, String and Address types are closely related as they are



Calhoun et al.             expires April 2001                  [Page 12]


INTERNET DRAFT                                              October 2000


   all application specific interpretations of strings of octets. So
   rather having the specific semantics for addresses or printable
   strings in the base data types, it seems desirable to collaps these
   three types into a single OctetString or Data type and to let the
   (extension specific) AVPs define the special semantics.

   There is a RADIUS AVP which uses 32 bit IEEE floating point values.
   It should be considered whether there is a need to provide support
   for 32, 64 and 128 bit IEEE floating point numbers. (Note again that
   the addition of new base types later on is extremely costly.)

   The Complex data type should be avoided as it usually requires code
   changes when it is being used.  It is suggested that the 'Grouped'
   type should replace 'Complex' and that Grouped be composed of a well
   known sequence of base data types.

   It has also been suggested that an additional data type could be
   added: List.  Lists would include items of identical type, whose
   length is only known at the time the list is generated or
   interpreted.


9.3 Formal notation for application specific data types

   The use of a formal notation for the definition of (potentially
   complex) application specific data types has proven to be valuable,
   especially if a protocol is designed the be extensible. A formal
   notation enables tools that can (a) verify the correctness of data
   definitions, (b) automate some of the implementation process, (c)
   help in debugging scenarios, and (d) enable implementations that can
   be easily adapted to vendor specific extensions. Furthermore, the
   separation of the data definitions from the core protocol
   specification allows extension writers to re-use existing data
   definitions (e.g. for addressing types) and it thus promotes
   consistency across a variety of management protocols.

   The formal notation will serve the extensibility of AAA
   implementations in terms of their data storage, interpretation,
   validation, display, etc.  Support for the formal notation is in this
   sense an implementation option to enhance support ease the
   integration of extensions, but not required for compliance.

   The formal notation is not intended to define the transfer encoding
   (the on-the-wire byte formatting). The DIAMETER specifications of the
   base types include these definitions and rules.


9.3.1 Goals for formal notation



Calhoun et al.             expires April 2001                  [Page 13]


INTERNET DRAFT                                              October 2000


   The goals for developing a formal notation would be to facilitate the
   implementation of various functions, such as a data dictionary, a
   packet filter or an extensible administrative console.  Such
   facilities have been shown to be useful in RADIUS implementations.

   The facilities based on formal notation for supported AVP would:

      - make it possible to add new AVP storage, type checking, etc.
        support without changing code.
      - make it easier to extend functionality to sniffers, debuggers
        management tools and DIAMETER implementations (potentially
        without adding code).

   Non-goals are to define a formal notation which can express any
   possible (i.e., non-DIAMETER) message.  We only need to express
   DIAMETER messages which have been currently defined and those
   messages which are likely to be defined, given experience with
   RADIUS. It is thought that support for extensible functions would be
   a useful but not mandatory feature for DIAMETER implementations.


9.3.2 How to evaluate proposals for formal data type languages

   The 'metrics' by which proposals for a formal notation and additional
   data types for DIAMETER data will be assessed are:

      - Is it possible to specify the existing DIAMETER messages?
      - Is the formal specification language tied to standards which are
        expected to remain stable (that is, not expected to change in
        the near to medium term)?
      - It is clear that using groups or lists of primitive data types
        will be less efficient than a complex data type (which could
        include byte by byte data fields, for example, and would not
        require AVP headers for each element in the data group/ data
        table.  Still, it is reasonable to sacrifice some efficiency for
        the sake of simplifying protocol implementation and facilitating
        formalization of data types as described above.  If messages
        are, for example, 20% larger that would be more acceptable than
        if they became 50% larger.  If messages became 100% larger, it
        would be difficult to accept the alternative to the current


9.4 Ordering of Data

   The current DIAMETER specification says that AVPs can be added
   arbitrarily as long as the required AVPs are included and AVPs which
   are explicitly excluded are not included. Some specific AVPs however
   introduce special requirements and even dependencies between AVPs.



Calhoun et al.             expires April 2001                  [Page 14]


INTERNET DRAFT                                              October 2000


   (The Session-Id AVPs SHOULD appear first, Integrity-Check-Value AVPs
   must follow the data to be protected, the Nonce AVP must appear
   before an Integrity-Check-Value AVP, the last Nonce AVP before an
   Encrypted-Payload AVP is significant for MD5 payload hiding and so
   on.)

   It seems useful to formally define the ordering constraints,
   potentially restricting the "AVPs can be added arbitrarily" rule to
   simplify the validation of messages. Note that it is necessary to
   provide for optional AVPs within a message so that the optional AVPs
   can be protected by an Integrity-Check-Value AVP.


9.5 Data Model Action Item List

   The action items identified in this section are summarized as
   follows:

      1.) How could the DIAMETER message header be made to easily
          distinguish between Request, Answer, Query, Response and
          Indication messages?
      2.) What basic data types specifically should be included?  We
          would need to look at all RADIUS extensions to see if we've
          missed any types.
      3.) How would List and Grouped data types be transmitted over the
          wire?
      4.) What formal notation could be used for DIAMETER messages?
          Assess these according to the goals and metrics described in
          Section 9.


10.0 SNMP Support (DIAMETER MIB)

10.1 Configuration of Sensitive Parameters

   A decision needs to be reached as to whether the Diameter MIB(s)
   should include "sensitive" parameters. Sensitive parameters include
   shared secrets, certificates, keys, security policies, and any other
   information that would facilitate an attack on any Diameter peer.
   The first step would be to create a list of all Diameter management
   parameters. The Diameter draft [1] already includes much of this
   information. These parameters should then be classified by level of
   sensitivity.

   It may be possible to take advantage of the security features of
   SNMPv3 [ref] to allow for complete remote configuration of Diameter
   peers (clients, servers proxies). The level of security available
   within SNMPv3 should be evaluated against the level of sensitivity of



Calhoun et al.             expires April 2001                  [Page 15]


INTERNET DRAFT                                              October 2000


   the Diameter management parameters.

   It has been pointed out that security may be compromised when key
   material from one protocol is carried in a second protocol,
   especially when the second protocol has weaker cryptographic
   protections or is not a key distribution protocol that has been
   thoroughly analyzed in the published cryptographic literature so that
   there is high confidence that it is sound. Many in the security
   community consider it strongly undesirable to have cascading
   vulnerabilities, whereby a compromise or implementation problem in
   one protocol necessarily leads to a compromise of a second protocol.

   The RADIUS MIB [17,18,19,20] was written when SNMPv1 and SNMPv2C were
   all we had, and thus avoided any sensitive configuration parameters
   that would have posed a security risk for remote access. There are
   interesting problems to be solved to obtain remote plug-'n-play
   configuration of Diameter peers using SNMP and/or some other suitable
   protocol, such as IKE [16] or Kerberos [21], but this is a desirable
   design goal.


10.2 Modular MIB(s)

   Diameter should probably have a series of MIBs covering the base
   protocol in its various roles: client, server and proxy, as well as
   each of its functional extensions. Counters, such as provided in the
   RADIUS MIB, should be included, as well as metrics and policy
   information that might aid in remote problem resolution of specific
   areas, such as proxy operations.

   The list of Diameter management parameters should also be categorized
   by the peer role(s) to which each parameter applies. The goal is to
   permit modular MIB deployment description to match the modular
   feature deployment. As an alternative, a single MIB could be written,
   together with Module Compliance Statements, indicating which subset
   of objects must be implemented in a given peer, by optional function
   and by optional role.


10.3 Traps and Informs

   A list of significant events occurring within Diameter peers needs to
   be compiled.  From this list of events, recommendations for Traps
   and/or Informs for use within the Diameter MIB(s) should be
   presented.


10.4 SNMP Action Item List



Calhoun et al.             expires April 2001                  [Page 16]


INTERNET DRAFT                                              October 2000


   The action items identified in this section are summarized as
   follows:

      1.) List all Diameter peer managed objects.
      2.) Categorize the list of managed objects by optional role and
          optional function.
      3.) Categorize the list of managed objects by security
          sensitivity.
      4.) Analyze SNMPv3, IKE, Kerberos and any other suitable protocols
          as to applicability, from a security perspective, for carrying
          the managed objects that are deemed sensitive.
      5.) Analyze the proposed MIB for remote plug-'n-play configuration
          capabilities.
      6.) Investigate both a single MIB with appropriate (conditional)
          Module Compliance Statements, as well as multiple MIBs, for
          modularity mirroring the Diameter Extension drafts.
      7.) Compile a list of significant Diameter peer events.
      8.)  Recommend Traps and Informs for inclusion in the MIB(s).


11.0 Re-Authentication & Authorization

   The AAA protocol must be able to support dynamic re-Authentication
   [1,3] initiated by either the NAS or the Server.

   Typical uses are periodic CHAP re-authentication, or server re-
   authentication probes.

   There should be a clear description of the messages and commands used
   to initiate a re-authentication from the NAS or server end.

   What is there:
      - Mentioned in Base in the section 1.0 wrt to unsolicited
        messages.
      - Mentioned in NASreq in the context of EAP auth.

   What is missing:
      - How such an unsolicited message would be recognized as a re-auth
        by the server vs a new request
      - What message for a server to use to request re-auth and how a
        NAS correlates that with an existing session
      - What information  is allowable in each message (AVP list)

   The AAA protocol must be able to support dynamic re-Authorization
   [2,4] initiated by either the NAS or the Server.

   Typical uses are the changing of service parameters (e.g. Packet
   filters or Session expiration timers).



Calhoun et al.             expires April 2001                  [Page 17]


INTERNET DRAFT                                              October 2000


   There should be a clear description of the messages and commands used
   to initiate a re-authentication from the NAS or server end.

   What is there:  anything??

   What is missing:
      - How would a NAS request a re-authorization?
      - How would a Server indicate a re-authorization?  Specify
        messages, commands, AVP datum
      - How are these messages differed from new requests, and
        correlated with existing sessions?

   Note that a related but different topic, termination of session
   service is already covered by the Base document, section 3.4, and
   three messages are described there:

      - Session-Termination-Request (STR) NAS->Server,
      - Session-Termination-Indication (STI) Server->NAS, and
      - Session-Termination-Answer(STA) acknowledgement


12.0 Server/Resource Management State

   Some implementations of RADIUS supported explicit resource management
   between the NAS and a server for authorized and active sessions [12].
   They implemented a simple resource request/response protocol, where
   the NAS requested and freed resources managed by the server, with
   distinct messages. Typical resources managed this way would be IP
   addresses, concurrent login counts, tunnel session limits, or
   resource usage based authorization limits.

   That this happens after authentication, allows the NAS to only
   request the resources actually needed to provide the service.
   Whereas authorization parameters in an Access-Accept may anticipate
   resources not actually needed (like additional addresses for a
   multi-link sessions, where the multi-link status could not be
   determined until after authentication).  Likewise, some network
   requirements cannot be determined until PPP NCP negotiation.

   The Diameter protocol should be able to provide similar functions
   [13,14]. An extensible set of resources should be able to be
   allocated and deallocated by the NAS, upon request to the server.
   The server then serves as a management point of the resource for all
   clients of the server.  This service would be optional to the
   implementation.

   Additional capability should be provided, where the server or client
   may interrogate identified resource's status, and the server can



Calhoun et al.             expires April 2001                  [Page 18]


INTERNET DRAFT                                              October 2000


   revoke or modify the resource status [14].  This is similar to the
   ability to re-authorize NAS services from the Server.

   This type of service MAY be robust in nature, in that the server may
   use a permanent store, or a state distribution protocol to
   synchronize backup servers between outages. The reliability of such a
   service will be implementation and configuration dependent.  The
   design of high availability state protocol is beyond the scope of
   what we wish to attempt at this time.  Only an interface would be
   specified.

   Such a service must scale reasonably in the presence of proxy
   systems. Broadcast or wildcard querys will not be allowed. It is
   highly likely that resources may be managed is different locations.
   For example, IP addresses may be managed locally, while user login
   concurrency checking could be done remotely.

   Maintenance of a consistent image of resources in use is a genuinely
   hard problem in the face of server, NAS and network failures and PDU
   reordering. The protocol support should give clear guidance to
   implementors of the known implementation techniques, such as upstream
   querying by a recovering server, periodic reconfirm  (aka interim
   accting) by the NAS, & inter-server replication.  And on the danger
   of self-inflicted DoS if the model is not somehow self-correcting.


13.0  Access Rules and Filters

   The AAA protocol must support powerful semantics for setting
   constraints on what an authenticated user may do.  That is, it should
   lean toward being able to invoke any capability that any NAS can
   provide in this area, rather than restrict itself to being able to
   express things that every NAS can provide - because the latter is
   completely inadequate to protect the Internet against malicious
   users.

   Examples of specific expressive power that must be provided:
      - source address assurance
      - prevention of IP options
      - prevention of specific IP options, such as source routing
      - prevention of malicious fragmentation, such as offset=1
      - restriction of SMTP connections to the home server only
      and so on.

   This implies of course that the action of the NAS when it cannot
   support a particular filter capability must be specified.  (Here
   'NAS' might really be a proxy that translates the AAA syntax to
   vendor-specific syntax for the particular NAS.)



Calhoun et al.             expires April 2001                  [Page 19]


INTERNET DRAFT                                              October 2000


13.1 Access Rules and Filters Action Item List

   The action items identified in this section are summarized as
   follows:

      1.) Design a syntax for access rules and filters that has
          sufficient expressive power use in current and clearly
          foreseeable networks.  Extensibility and ability to
          incorporate vendor-specific capabilities are highly desirable.
      2.) Specify NAS behavior when it is unable to implement a
          particular rule.


14.0 AAA Server Discovery

   In some cases, AAA servers may be dynamically discovered.  This
   allows for more robust deployments of network access services, for
   example.  If a primary AAA server fails, for which a AAA client is
   configured, the AAA client can discover another suitable AAA server.
   In order to promote interoperable implementations, a definite 'search
   order' should be recommended, if dynamic service discovery is
   employed.  For example, the search order could be (1). Use static
   (manual) configuration if it exists.  (2).  Use DNS SRV RR for
   DIAMETER services, if it exists. (3).  Use SLP to discover
   administratively DIAMETER services.

   Dynamic discovery of AAA servers will only be secure if previous
   configuration provided AAA clients with the security parameters which
   can be used to authenticate the discovered AAA server.  This is
   possible, for instance, using DNS security, SLPv2 authentication,
   etc.

   In some respects configuring hosts to enable them to do dynamic
   configuration seems at cross purposes.  Here the goal is not zero
   administration but rather robust deployment (so clients can
   automatically find servers, for instance, in the case  that a server
   fails or is swapped out).


14.1 Server Discovery Action Item List

   The action items identified in this section are summarized as
   follows:

      1.) Specific worked out solutions for how to discover AAA servers
          both locally (in the same administrative domain) or across the
          internet.
      2.) For each of the above solutions, describe how the mechanism



Calhoun et al.             expires April 2001                  [Page 20]


INTERNET DRAFT                                              October 2000


          could be made secure, so that AAA clients could verify that
          the AAA server they discover is 'trustworthy' according to
          some policy.  What preconfiguration is needed?  What policy
          (with respect to trust) is implied by possesion of a key?


15.0 Loop Detection

   In current RADIUS networks, it is possible for an improperly
   configured domain routing table to cause messages to be stuck in a
   loop. The DIAMETER protocol does not provide any loop detection, and
   therefore is subjected to the same problem.

   The Mobile IP extension does have a require that some messages
   destined for the home DIAMETER server be sent back to the visited
   DIAMETER server for Home Agent allocation. Therefore, the loop
   detection must be designed to in such a way that the Mobile IP
   extension can still be used as specified.


15.1 Loop Detection Action Item List

   The action items identified in this section are summarized as
   follows:

      1.) Determine how the protocol can be enhanced to detect loops,
          without breaking end-to-end security.
      2.) Ensure that the mechanism does allow for certain messages to
          loop back to the requestor, when it is intended to do so.


16.0  IANA Considerations

   DIAMETER makes extensive use of IDs (command codes, extensions,
   result codes, AVP attributes, Integrity-Check-Value AVP Transform
   code).  These are collected in the base protocol specification, but
   defined in the DIAMETER extension docs.


17.0  Security Considerations

   DIAMETER [1] is a framework providing authentication and
   authorization services for network access.  Section 11 and 13 concern
   how these features could be refined or improved in subsequent work.

   DIAMETER itself contains a number of security features.  Section 8
   discusses how these could be redesigned for less reliance on public
   key cryptography.



Calhoun et al.             expires April 2001                  [Page 21]


INTERNET DRAFT                                              October 2000


18.0  Acknowledgments

   The authors would like to thanks Ran Atkinson for his valuable
   comments.


19.0  References


   [1]  P. Calhoun, A. Rubens, H. Akhtar, E. Guttman.  "DIAMETER Base
        Protocol", draft-calhoun-diameter-17.txt, IETF work in progress,
        September 2000.

   [2]  P. Calhoun, W. Bulley, A. Rubens, J. Haag, "DIAMETER NASREQ
        Extension", draft-calhoun-diameter-nasreq-05.txt, IETF work in
        progress, September 2000.

   [3]  Calhoun, Zorn, Pan, Akhtar, "DIAMETER Framework", draft-
        calhoun-diameter-framework-08.txt, IETF work in progress, June
        2000.

   [4]  P. Calhoun, C. Perkins, "DIAMETER Mobile IP Extensions", draft-
        calhoun-diameter-mobileip-11.txt, IETF work in progress, Sep-
        tember 2000.

   [5]  P. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security
        Extension", draft-calhoun-diameter-strong-crypto-05.txt (work in
        progress), September 2000.

   [6]  Arkko, Calhoun, Patel, Zorn, "DIAMETER Accounting Extension",
        draft-calhoun-diameter-accounting-08.txt, IETF work in progress,
        September 2000.

   [7]  P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, W. Bulley, J.
        Haag, "DIAMETER Implementation Guidelines", draft-calhoun-
        diameter-impl-guide-03.txt, IETF work in progress, June 2000.

   [8]  P. Calhoun, N. Greene, "DIAMETER Resource Management", draft-
        calhoun-diameter-res-mgmt-05.txt, IETF Work in Progress, Sep-
        tember 2000.

   [9]  Aboba et al, "Network Access AAA Evaluation Criteria", IETF work
        in progress, draft-ietf-aaa-na-reqts-07.txt, August 2000.

   [10] Mitton et al, "Authentication, Authorization, and Accounting:
        Protocol Evaluation", IETF work in progress, draft-ietf-aaa-
        proto-eval-00.txt, July 2000.




Calhoun et al.             expires April 2001                  [Page 22]


INTERNET DRAFT                                              October 2000


   [11] Rigney, et alia, "RADIUS", RFC-2138, April 1997

   [12] RFC 2882 "NASReq Extended RADIUS Practices", Sect 6, page 9-10

   [13] draft-ietf-nasreq-criteria-05.txt, Sect 8.3.1.2 page 10

   [14] draft-ietf-aaa-na-reqts-07.txt, Sect 4.4.3.3 Authorization
        Requirements, State Reconciliation, Note f

   [15] B. Aboba, D. Lidyard, "The Accounting Data Interchange Format
        (ADIF)", draft-ietf-roamops-actng-07.txt, IETF work in progress,
        April 2000.

   [16] D. Harkins, D. Carrell, "The Internet Key Exchange (IKE)", RFC
        1409, November 1998.

   [17] B. Aboba, G. Zorn, "RADIUS Authentication Client MIB", RFC 2618,
        June 1999.

   [18] G. Zorn, B. Aboba, "RADIUS Authentication Server MIB", RFC 2619,
        June 1999.

   [19] B. Aboba, G. Zorn, "RADIUS Accounting Client MIB", RFC 2620,
        June 1999.

   [20] G. Zorn, B. Aboba, "RADIUS Accounting Server MIB", RFC 2621,
        June 1999.

   [21] J. Kohl, C. Neuman, "The Kerberos Network Authentication Service
        (V5)", RFC 1510, September 1993.


20.0  Authors' Addresses

   Questions about this memo can be directed to:

      Pat R. Calhoun
      Network and Security Research Center, Sun Labs
      Sun Microsystems, Inc.
      15 Network Circle
      Menlo Park, California, 94025
      USA

       Phone:  +1 650-786-7733
         Fax:  +1 650-786-6445
      E-mail:  pcalhoun@eng.sun.com





Calhoun et al.             expires April 2001                  [Page 23]


INTERNET DRAFT                                              October 2000


      Bernard Aboba
      Microsoft Corporation
      One Microsoft Way
      Redmond, WA 98052
      USA

       Phone:  +1 425 936-6605
         Fax:  +1 425 936-7329
      E-mail:  bernarda@microsoft.com


      Erik Guttman
      Network and Security Research Center, Sun Laboratories
      Sun Microsystems, Inc.
      Eichhoelzelstr. 7
      74915 Waibstadt
      Germany

       Phone:  +49-7263-911-701
      E-mail:  erik.guttman@germany.sun.com


      David Mitton
      Nortel Networks
      880 Technology Park Drive
      Billerica, MA 01821
      USA

       Phone:  +1 978 288 4570
      E-mail:  dmitton@nortelnetworks.com


      David B. Nelson
      Enterasys Networks, Inc. (a Cabletron Systems company)
      50 Minuteman Road
      Andover, MA 01810-1008
      USA

       Phone:  +1 978 684 1330
      E-Mail:  dnelson@enterasys.com


      Juergen Schoenwaelder
      Technical University Braunschweig
      Dept. Operating Systems & Computer Networks
      Bueltenweg 74/75, 38106 Braunschweig,
      Germany




Calhoun et al.             expires April 2001                  [Page 24]


INTERNET DRAFT                                              October 2000


       Phone:  +49 531 391 3289
         Fax:  +49 531 391 5936
      E-Mail:  schoenw@ibr.cs.tu-bs.de


      Barney Wolff, Pres.
      Databus Inc.
      15 Victor Drive
      Irvington, NY 10533-1919 USA
      USA

       Phone:  +1 914 591 5677
      E-mail:  barney@databus.com


      Lixia Zhang
      UCLA Computer Science Department
      4531G Boelter Hall
      Los Angeles, CA 90095-1596
      USA

       Phone:  +1 310 825 2695
      E-Mail:  lixia@cs.ucla.edu


21.0  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this docu-
   ment itself may not be modified in any way, such as by removing the
   copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of develop-
   ing Internet standards in which case the procedures for copyrights
   defined in the Internet Standards process must be followed, or as
   required to translate it into languages other than English. The lim-
   ited permissions granted above are perpetual and will not be revoked
   by the Internet Society or its successors or assigns. This document
   and the information contained herein is provided on an "AS IS" basis
   and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS-
   CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
   TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
   INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR



Calhoun et al.             expires April 2001                  [Page 25]


INTERNET DRAFT                                              October 2000


   FITNESS FOR A PARTICULAR PURPOSE.


















































Calhoun et al.             expires April 2001                  [Page 26]