Subject: Comments on draft-ietf-nasreq-criteria-02.txt

From: [email-masked]
Date: Wed, 6 Oct 1999 17:28:14 -0700 (PDT)

Mark,

Here are my comments on the draft. Sorry they are so extensive that it
looks like most of the I-D is included in this e-mail. I did it this way
because in most cases some context is needed to understand the comment.

Good work, btw.

PatC
----

     5.  Introduction

     This  document  defines  requirements  for  protocols  used by Network
     Access Servers (NAS).Protocols used by NAS's may be divided into  four
     spaces:   Access  protocols,  Network  protocols,  AAA  protocols, and
     Device Management protocols.   The primary focus of this  document  is
     on AAA protocols.  The reference model of a NAS used by this document,
     and the analysis of the functions of a NAS which led to  the  develop-
     ment of these requirements, may be found in [NAS-MODEL].
PRC: Nit. Space is missing before Protocols in second sentence.

     6.  Access Protocol Requirements

     There  are three basic types of access protocols used by NAS's.  First
     are the traditional telephony-based access protocols, which  interface
     to  the  NAS  via a modem or terminal adapter or similar device. These
     protocols typically support asynchronous or synchronous PPP [PPP] car-
     ried over a telephony protocol.
PRC: What is a telephony protocol? Q.931?
     Second are broadband pseudo-telephony
     access protocols, which are carried over xDSL  or  cable  modems,  for
     example.   These  protocols  typically support an encapsulation method
     such as PPP over Ethernet [PPPOE].  Finally  are  the  virtual  access
     protocols  used  by NAS's that terminate tunnels.  One example of this
     type of protocol is L2TP [L2TP].
PRC: What about cellular devices, such as in the 3G model. Initially the
devices will connect via PPP, but there is talk to also support HDLC in
order to get rid of PPP (since we that is needed is the framing).

     It is a central assumption of the NAS  model  used  here  that  a  NAS
     accepts multiple point-to-point links via one of the above access pro-
     tocols.  Therefore, at a minimum, any NAS access protocol MUST be able
     to  carry  PPP.   The  exception to this requirement is for NAS's that
     support legacy text login methods such as telnet [TELNET], rlogin,  or
     LAT.   Only  these access protocols are exempt from the requirement to
     support PPP.
PRC: So have we abandoned SLIP? I am not stating that we need to support it.
I am just curious.

     8.1.1.1.  Transport independence

     The AAA protocol MUST be transport independent, and MUST be capable of
     using both TCP and UDP as a transport.   Additionally, the AAA  proto-
     col  SHOULD  be designed to easily support any new transport protocols
     developed by the Internet standards community.
PRC:Having an AAA protocol support both TCP and UDP has brought *lots* of criticism from the likes of Fred Baker. In fact, due to such pressures one protocol that comes to mind now only supports UDP. This specific protocol
had support for both because the applications people did not need fast
fail-over, but I think that nasreq is a good candidate for fast fail-over.

    8.1.1.2.  Long-term exchange of small packets

     Very large scale NAS's that serve up to thousands of simultaneous ses-
     sions  are now being deployed.  This means that, in the extreme, there
     may be an almost constant exchange of many small packets  between  the
     NAS  and  the  AAA  server.   An AAA protocol transport SHOULD support
     being optimized for a long-term exchange of small packets in a  stream
     between a pair of hosts.
PRC: So are we talking about multiple sub-requests within a single request?
If so, this adds some interesting problems in roaming environments where part
of a request goes to A, and the other part to B.

     8.1.1.3.  Support for multiple AAA servers

     In  order to operationally support large loads, load balancing to mul-
     tiple AAA servers will be required.  The AAA protocol MUST provide for
     NAS's  to  balance  AAA sessions between two or more AAA servers.  The
     load balancing mechanism SHOULD  be  built  in  to  the  AAA  protocol
     itself.   The AAA protocol design MUST NOT introduce a single point of
     failure during the AAA process.  The AAA protocol MUST allow any  ses-
     sions between a NAS and a given AAA server to fail over to a secondary
     server without loss of state information.   This  fail-over  mechanism
     SHOULD be built in to the AAA protocol itself.
PRC: I think that is *also* needed here is a method to flow the traffic between
the NAS and the server. Otherwise, flodding a server that is already
busy is pointless. This would allow for a more effective load balancing
mechanism.

     8.1.1.4.  Support for Multiple Administrative Domains
[...]
     port proxy, and in additiona SHOULD support other  multi-domain  rela-
     tionships such as brokering and referral.
PRC: Should read "addition"

     8.1.2.  Attribute-Value Protocol Model

[...]
     Experience has also shown  that  attribute  space  tends  to  run  out
     quickly.  In  order  to  provide  room  for expansion in the attribute
     space, the AAA protocol MUST support a minimum of 64K  Attributes  (16
     bits), each with a minimum length of 64K (16 bits).
PRC: Of course, my preference here is 32 bit since if the protocol is properly
aligned on a 32-bit boundary, it will be more CPU friendly. This will allow
for a higher number of transactions/sec.

     8.1.2.1.  Attribute Data Types

     The  AAA  protocol MUST support simple attribute data types, including
     integer, enumeration, text string, IP address, and date/time. The  AAA
     protocol  MUST  also  provide some support for complex structured data
     types. Wherever IP addresses are carried within the AAA protocol,  the
     protocol  MUST  support  both IPv4 and IPv6 [IPV6] addresses. Wherever
     text information is carried within the AAA protocol, the protocol MUST
     comply  with  the  IETF  Policy  on  Character Sets and Languages [RFC
     2277].
PRC: The requirement for IP V6 is interesting. Note that one data type is just
a series of octets, not necessarily a string (e.g. challenge).

     8.1.2.3.  Attribute Extensibility

[...]
     The AAA protocol MUST include a means for individual  vendors  to  add
     value  through  vendor-specific  attributes and SHOULD include support
     for vendor-specific data types.
PRC: No mention for vendor specific commands? Is this also a requirement?

     8.1.3.1.  Mutual Authentication

     It is poor security practice for a NAS  to  communicate  with  an  AAA
     server  that  is  not  trusted, and vice versa.  The AAA protocol MUST
     provide mutual authentication between AAA server and NAS.
PRC: Although it should be possible for the protocol to make use of an underlying security protocol, such as AH/EAP. However, in practice this is more difficult since the application cannot guarantee that the policy is correctly setup and could in fact be sending sensitive information unprotected in the clear. However, if a network operator has deployed IP Security, the protocol should allow it.

     8.1.3.3.  Public Key Security

     AAA server/NAS identity verification based solely  on  shared  secrets
     can  be  difficult  to  deploy  properly at large scale, and it can be
     tempting for NAS operators to use a single shared secret (that  rarely
     changes)  across  all  NAS's.  This can lead to easy compromise of the
     secret.  Therefore, the AAA protocol MUST also support mutual  verifi-
     cation  of  identity  using  a public-key infrastructure that supports
     expiration and revocation of keys.
PRC: I think that for hop-by-hop security, IP Security would provide this
and would allow for re-keying. Should the AAA protocol also provide this?
I believe that it may in inter-domain cases since it MAY be a requirement
to include non-repudiation within an accounting record, and this wouldn't
be possible with IP Security.

     8.2.1.4.  Extensible Authentication Types

     Security protocol development is going on constantly  as  new  threats
     are  identified  and  better  cracking methods are developed.  Today's
     secure authentication methods may be proven  insecure  tomorrow.   The
     AAA protocol MUST provide some support for addition of new authentica-
     tion credential types.
PRC: Should we simply call for EAP here? Or are we talking about AAA-transport
security?

    8.2.2.2.  User Identification

[...]
     If a particular type of identity credential is not needed for  a  par-
     ticular  user  session,  the  AAA protocol MUST NOT require that dummy
     credentials be filled in.  That is,  the  AAA  protocol  MUST  support
     identification without authentication.
PRC: Or perhaps the other way around?

     8.2.2.3.  Authentication Credentials

[...]
          -A secret or password.

          -A response to a challenge presented by the NAS to the user

          -A one-time password

          -An X.509 digital certificate [X.509]

          -A Kerberos v5 ticket [KERBEROS]
PRC: I am not sure that I get it. I think that each authentication scheme
has it's own type of credential, so what is this section intended to state?

     8.2.3.1.  End-to-End Hiding of Credentials

     Where passwords are used as authentication credentials, the AAA proto-
     col MUST provide a secure means of hiding the password from end to end
     of  the  AAA  conversation.   Where  challenge/response mechanisms are
     used, the AAA protocol MUST also prevent against replay attacks.

PRC: I would prefer to see end-to-end authentication. Glen and I have a draft that
talks about this, and this effectively eliminates the authentication replay problem
that occurs with CHAP/RADIUS today.

     8.3.1.2.  Resource Management

     Resource management MUST be supported on demand  by  the  NAS  or  AAA
     Server at any time during the course of a user session.
PRC: Inter-Domain resource management can be *very* difficult. However the
I-D that Glen and I put together makes it scale across the Internet by
requiring periodical re-authentication.

     8.3.2.1.  Authorization Attribute Requirements - Access Restrictions

[...]
          -Time/day restrictions.  The AAA protocol MUST be able to provide
          an  unambiguous  time  stamp,  NAS time zone indication, and date
          indication to the AAA server in the Authorization information.
PRC: This is good, and the work in Secure NTP will certainly help. This is
especially true in inter-domain cases where assuming that all hosts are time
synched is difficult.

          -Location restrictions:  The AAA protocol MUST be able to provide
          an  unambiguous  location code that reflects the geographic loca-
          tion of the NAS.  Note that this is not the same type of thing as
          either the dialing or dialed station.
PRC: I hear privacy issues here, but perhaps it *could* be a requirement. I
am not sure that I'd want anyone to know that I am in a cyber-coffee shop
somewhere in the Netherlands.

[...]
          -Concurrent login limitations:  The AAA protocol  MUST  allow  an
          AAA  Server  to  limit  concurrent logins by a particular user or
          group of users.  This mechanism does not need  to  be  explicitly
          built  into  the  AAA protocol, but the AAA protocol must provide
          sufficient authorization information for an AAA  server  to  make
          that determination through an out-of-band mechanism.
PRC: Working on the draft with Glen and previous exercises with Merit to come
up with such a scheme for inter-domain has lead me to believe that this is
a very difficult problem. However, one can get similar functionality if you
use the scheme described in the draft that Glen and I put together.

     8.3.2.2.   Authorization  Attribute  Requirements - Authorization Pro-
     files
[...]
          -Protocol Filter application:  The AAA protocol  MUST  provide  a
          means of applying IP protocol filters to user sessions.  Two dif-
          ferent methods MUST be supported.

          First, the AAA protocol MUST provide a means of selecting a  pro-
          tocol  filter  by reference to an identifier, with the details of
          the filter action being specified out of band.  The AAA  protocol
          SHOULD define this out-of-band reference mechanism.
PRC: This smells of scaling problems.

     8.3.3.1.  Security of Compulsory Tunnel Credentials

     When an AAA protocol passes credentials that will be used to authenti-
     cate compulsory tunnels, the AAA protocol  MUST  provide  a  means  of
     securing the credentials from end to end of the AAA conversation.  The
     AAA protocol MUST also provide protection against  replay  attacks  in
     this situation.
PRC: Is this the authentication blob, or the username?

     8.4.1.1.  Guaranteed Delivery

     The accounting and auditing functions of the AAA protocol are used for
     network planning, resource management,  policy  decisions,  and  other
     functions  that  require  accurate  knowledge of the state of the NAS.
     NAS operators need to be able to engineer their network usage measure-
     ment  systems  to  a predictable level of accuracy.  Therefore, an AAA
     protocol MUST provide a means of  guaranteed  delivery  of  accounting
     information between the NAS and the AAA Server(s).
PRC: My experience is that hop-by-hop delivery acknowledgement is the best way
since it reduces the traffic, and the end-to-end retransmissions known to
exist in RADIUS.

     8.4.1.4.  Accounting Time Stamps

     There may be delays associated with the delivery of accounting  infor-
     mation.   The NAS operator will desire to know the time an event actu-
     ally occurred, rather than simply the time when  notification  of  the
     event  was  received.  Therefore, the AAA protocol MUST carry an unam-
     biguous time stamp associated with each accounting event.   This  time
     stamp  MUST  be  unambiguous with regard to time zone.  Note that this
     assumes  that  the  NAS  has  access  to  a   correct   time   source.
PRC: Does it matter if an intermediate node changes the time? Or does the time
have the be protected end-to-end?

     8.4.3.2.  Non-repudiation

     Network operators use accounting data for network  planning,  resource
     management,  and other business-critical functions that require confi-
     dence in the correctness of this data. The AAA protocol SHOULD provide
     a  mechanism to ensure that the source of Accounting data cannot repu-
     diate this data after transmission.
PRC: non-repudiation of both the source and the destination means that sufficient
data must be present in the accounting response. This allows the sender to
prove that the peer did in fact receive, and acknowledge receipt of the
accounting data.