doc/rfc/rfc4849.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                         P. Congdon
   8 Request for Comments: 4849                                    M. Sanchez
   9 Category: Standards Track                      ProCurve Networking by HP
  10                                                                 B. Aboba
  11                                                    Microsoft Corporation
  12                                                               April 2007
  13
  14
  15                       RADIUS Filter Rule Attribute
  16
  17 Status of This Memo
  18
  19    This document specifies an Internet standards track protocol for the
  20    Internet community, and requests discussion and suggestions for
  21    improvements.  Please refer to the current edition of the "Internet
  22    Official Protocol Standards" (STD 1) for the standardization state
  23    and status of this protocol.  Distribution of this memo is unlimited.
  24
  25 Copyright Notice
  26
  27    Copyright (C) The IETF Trust (2007).
  28
  29 Abstract
  30
  31    While RFC 2865 defines the Filter-Id attribute, it requires that the
  32    Network Access Server (NAS) be pre-populated with the desired
  33    filters.  However, in situations where the server operator does not
  34    know which filters have been pre-populated, it is useful to specify
  35    filter rules explicitly.  This document defines the NAS-Filter-Rule
  36    attribute within the Remote Authentication Dial In User Service
  37    (RADIUS).  This attribute is based on the Diameter NAS-Filter-Rule
  38    Attribute Value Pair (AVP) described in RFC 4005, and the
  39    IPFilterRule syntax defined in RFC 3588.
  40
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58 Congdon, et al.             Standards Track                     [Page 1]
  59 \f
  60 RFC 4849                 Filter Rule Attribute                April 2007
  61
  62
  63 Table of Contents
  64
  65    1. Introduction ....................................................2
  66       1.1. Terminology ................................................2
  67       1.2. Requirements Language ......................................3
  68       1.3. Attribute Interpretation ...................................3
  69    2. NAS-Filter-Rule Attribute .......................................3
  70    3. Table of Attributes .............................................5
  71    4. Diameter Considerations .........................................5
  72    5. IANA Considerations .............................................6
  73    6. Security Considerations .........................................6
  74    7. References ......................................................7
  75       7.1. Normative References .......................................7
  76       7.2. Informative References .....................................7
  77    8. Acknowledgments .................................................7
  78
  79 1.  Introduction
  80
  81    This document defines the NAS-Filter-Rule attribute within the Remote
  82    Authentication Dial In User Service (RADIUS).  This attribute has the
  83    same functionality as the Diameter NAS-Filter-Rule AVP (400) defined
  84    in [RFC4005], Section 6.6, and the same syntax as an IPFilterRule
  85    defined in [RFC3588], Section 4.3.  This attribute may prove useful
  86    for provisioning of filter rules.
  87
  88    While [RFC2865], Section 5.11, defines the Filter-Id attribute (11),
  89    it requires that the Network Access Server (NAS) be pre-populated
  90    with the desired filters.  However, in situations where the server
  91    operator does not know which filters have been pre-populated, it is
  92    useful to specify filter rules explicitly.
  93
  94 1.1.  Terminology
  95
  96    This document uses the following terms:
  97
  98    Network Access Server (NAS)
  99       A device that provides an access service for a user to a network.
 100
 101    RADIUS server
 102       A RADIUS authentication server is an entity that provides an
 103       authentication service to a NAS.
 104
 105    RADIUS proxy
 106       A RADIUS proxy acts as an authentication server to the NAS, and a
 107       RADIUS client to the RADIUS server.
 108
 109
 110
 111
 112
 113
 114 Congdon, et al.             Standards Track                     [Page 2]
 115 \f
 116 RFC 4849                 Filter Rule Attribute                April 2007
 117
 118
 119 1.2.  Requirements Language
 120
 121    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 122    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
 123    document are to be interpreted as described in [RFC2119].
 124
 125 1.3.  Attribute Interpretation
 126
 127    If a NAS conforming to this specification receives an Access-Accept
 128    packet containing a NAS-Filter-Rule attribute that it cannot apply,
 129    it MUST act as though it had received an Access-Reject.  [RFC3576]
 130    requires that a NAS receiving a Change of Authorization Request
 131    (CoA-Request) reply with a CoA-NAK if the Request contains an
 132    unsupported attribute.  It is RECOMMENDED that an Error-Cause
 133    attribute with value set to "Unsupported Attribute" (401) be included
 134    in the CoA-NAK.  As noted in [RFC3576], authorization changes are
 135    atomic so that this situation does not result in session termination,
 136    and the pre-existing configuration remains unchanged.  As a result,
 137    no accounting packets should be generated because of the CoA-Request.
 138
 139 2.  NAS-Filter-Rule Attribute
 140
 141    Description
 142
 143    This attribute indicates filter rules to be applied for this user.
 144    Zero or more NAS-Filter-Rule attributes MAY be sent in Access-Accept,
 145    CoA-Request, or Accounting-Request packets.
 146
 147    The NAS-Filter-Rule attribute is not intended to be used concurrently
 148    with any other filter rule attribute, including Filter-Id (11) and
 149    NAS-Traffic-Rule [Traffic] attributes.  NAS-Filter-Rule and NAS-
 150    Traffic-Rule attributes MUST NOT appear in the same RADIUS packet.
 151    If a NAS-Traffic-Rule attribute is present, a NAS implementing this
 152    specification MUST silently discard any NAS-Filter-Rule attributes
 153    that are present.  Filter-Id and NAS-Filter-Rule attributes SHOULD
 154    NOT appear in the same RADIUS packet.  Given the absence in [RFC4005]
 155    of well-defined precedence rules for combining Filter-Id and NAS-
 156    Filter-Rule attributes into a single rule set, the behavior of NASes
 157    receiving both attributes is undefined, and therefore a RADIUS server
 158    implementation cannot assume a consistent behavior.
 159
 160    Where multiple NAS-Filter-Rule attributes are included in a RADIUS
 161    packet, the String field of the attributes are to be concatenated to
 162    form a set of filter rules.  As noted in [RFC2865], Section 2.3, "the
 163    forwarding server MUST NOT change the order of any attributes of the
 164    same type", so that RADIUS proxies will not reorder NAS-Filter-Rule
 165    attributes.
 166
 167
 168
 169
 170 Congdon, et al.             Standards Track                     [Page 3]
 171 \f
 172 RFC 4849                 Filter Rule Attribute                April 2007
 173
 174
 175    A summary of the NAS-Filter-Rule Attribute format is shown below.
 176    The fields are transmitted from left to right.
 177
 178     0                   1                   2                   3
 179     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
 180    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 181    |     Type      |    Length     |      String...
 182    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 183
 184    Type
 185
 186       92
 187
 188    Length
 189
 190       >=3
 191
 192    String
 193
 194       The String field is one or more octets.  It contains filter rules
 195       in the IPFilterRule syntax defined in [RFC3588], Section 4.3, with
 196       individual filter rules separated by a NUL (0x00).  A NAS-Filter-
 197       Rule attribute may contain a partial rule, one rule, or more than
 198       one rule.  Filter rules may be continued across attribute
 199       boundaries, so implementations cannot assume that individual
 200       filter rules begin or end on attribute boundaries.
 201
 202       The set of NAS-Filter-Rule attributes SHOULD be created by
 203       concatenating the individual filter rules, separated by a NUL
 204       (0x00) octet.  The resulting data should be split on 253-octet
 205       boundaries to obtain a set of NAS-Filter-Rule attributes.  On
 206       reception, the individual filter rules are determined by
 207       concatenating the contents of all NAS-Filter-Rule attributes, and
 208       then splitting individual filter rules with the NUL octet (0x00)
 209       as a delimiter.
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226 Congdon, et al.             Standards Track                     [Page 4]
 227 \f
 228 RFC 4849                 Filter Rule Attribute                April 2007
 229
 230
 231 3.  Table of Attributes
 232
 233    The following table provides a guide to which attributes may be found
 234    in which kinds of packets, and in what quantity.
 235
 236    Access- Access- Access- Access-   CoA-  Acct-
 237    Request Accept  Reject  Challenge Req   Req   #   Attribute
 238     0       0+      0       0        0+    0+    92  NAS-Filter-Rule
 239
 240    The following table defines the meaning of the above table entries.
 241
 242      0     This attribute MUST NOT be present in the packet.
 243      0+    Zero or more instances of this attribute MAY be
 244            present in the packet.
 245      0-1   Zero or one instance of this attribute MAY be
 246            present in the packet.
 247
 248 4.  Diameter Considerations
 249
 250    [RFC4005], Section 6.6, defines the NAS-Filter-Rule AVP (400) with
 251    the same functionality as the RADIUS NAS-Filter-Rule attribute.  In
 252    order to support interoperability, Diameter/RADIUS gateways will need
 253    to be configured to translate RADIUS attribute 92 to Diameter NAS-
 254    Filter-Rule AVP (400) and vice versa.
 255
 256    When translating Diameter NAS-Filter-Rule AVPs to RADIUS NAS-Filter-
 257    Rule attributes, the set of NAS-Filter-Rule attributes is created by
 258    concatenating the individual filter rules, separated by a NUL octet.
 259    The resulting data SHOULD then be split on 253-octet boundaries.
 260
 261    When translating RADIUS NAS-Filter-Rule attributes to Diameter NAS-
 262    Filter-Rule AVPs, the individual rules are determined by
 263    concatenating the contents of all NAS-Filter-Rule attributes, and
 264    then splitting individual filter rules with the NUL octet as a
 265    delimiter.  Each rule is then encoded as a single Diameter NAS-
 266    Filter-Rule AVP.
 267
 268    Note that a translated Diameter message can be larger than the
 269    maximum RADIUS packet size (4096 bytes).  Where a Diameter/RADIUS
 270    gateway receives a Diameter message containing a NAS-Filter-Rule AVP
 271    that is too large to fit into a RADIUS packet, the Diameter/RADIUS
 272    gateway will respond to the originating Diameter peer with a Result-
 273    Code AVP with the value DIAMETER_RADIUS_AVP_UNTRANSLATABLE (5018),
 274    and with a Failed-AVP AVP containing the NAS-Filter-Rule AVP.  Since
 275    repairing the error will probably require re-working the filter
 276    rules, the originating peer should treat the combination of a
 277    Result-Code AVP with value DIAMETER_RADIUS_AVP_UNTRANSLATABLE and a
 278    Failed-AVP AVP containing a NAS-Filter-Rule AVP as a terminal error.
 279
 280
 281
 282 Congdon, et al.             Standards Track                     [Page 5]
 283 \f
 284 RFC 4849                 Filter Rule Attribute                April 2007
 285
 286
 287 5.  IANA Considerations
 288
 289    This specification does not create any new registries.
 290
 291    This document uses the RADIUS [RFC2865] namespace, see
 292    <http://www.iana.org/assignments/radius-types>.  One value has been
 293    allocated in the section "RADIUS Attribute Types".  The RADIUS
 294    attribute for which a value has been assigned is:
 295
 296       92 - NAS-Filter-Rule
 297
 298    This document also utilizes the Diameter [RFC3588] namespace.  A
 299    Diameter Result-Code AVP value for the
 300    DIAMETER_RADIUS_AVP_UNTRANSLATABLE error has been allocated.  Since
 301    this is a permanent failure, the allocation (5018) is in the 5xxx
 302    range.
 303
 304 6.  Security Considerations
 305
 306    This specification describes the use of RADIUS for purposes of
 307    authentication, authorization and accounting.  Threats and security
 308    issues for this application are described in [RFC3579] and [RFC3580];
 309    security issues encountered in roaming are described in [RFC2607].
 310
 311    This document specifies a new attribute that can be included in
 312    existing RADIUS packets, which are protected as described in
 313    [RFC3579] and [RFC3576].  See those documents for a more detailed
 314    description.
 315
 316    The security mechanisms supported in RADIUS and Diameter are focused
 317    on preventing an attacker from spoofing packets or modifying packets
 318    in transit.  They do not prevent an authorized RADIUS/Diameter server
 319    or proxy from modifying, inserting, or removing attributes with
 320    malicious intent.  Filter attributes modified or removed by a
 321    RADIUS/Diameter proxy may enable a user to obtain network access
 322    without the appropriate filters; if the proxy were also to modify
 323    accounting packets, then the modification would not be reflected in
 324    the accounting server logs.
 325
 326    Since the RADIUS protocol currently does not support capability
 327    negotiation, a RADIUS server cannot automatically discover whether a
 328    NAS supports the NAS-Filter-Rule attribute.  A legacy NAS not
 329    compliant with this specification may silently discard the NAS-
 330    Filter-Rule attribute while permitting the user to access the
 331    network.  This can cause users to improperly receive unfiltered
 332    access to the network.  As a result, the NAS-Filter-Rule attribute
 333    SHOULD only be sent to a NAS that is known to support it.
 334
 335
 336
 337
 338 Congdon, et al.             Standards Track                     [Page 6]
 339 \f
 340 RFC 4849                 Filter Rule Attribute                April 2007
 341
 342
 343 7.  References
 344
 345 7.1.  Normative References
 346
 347    [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
 348              Requirement Levels", BCP 14, RFC 2119, March, 1997.
 349
 350    [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
 351              "Remote Authentication Dial In User Service (RADIUS)", RFC
 352              2865, June 2000.
 353
 354    [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
 355              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
 356
 357    [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter
 358              Network Access Server Application", RFC 4005, August 2005.
 359
 360 7.2.  Informative References
 361
 362    [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
 363              Implementation in Roaming", RFC 2607, June 1999.
 364
 365    [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
 366              Aboba, "Dynamic Authorization Extensions to Remote
 367              Authentication Dial In User Service (RADIUS)", RFC 3576,
 368              July 2003.
 369
 370    [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
 371              Dial In User Service) Support For Extensible Authentication
 372              Protocol (EAP)", RFC 3579, September 2003.
 373
 374    [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese,
 375              "IEEE 802.1X Remote Authentication Dial In User Service
 376              (RADIUS) Usage Guidelines", RFC 3580, September 2003.
 377
 378    [Traffic] Congdon, P., Sanchez, M., Lior, A., Adrangi, F., and B.
 379              Aboba, "RADIUS Attributes for Filtering and Redirection",
 380              Work in Progress, March 2007.
 381
 382 8.  Acknowledgments
 383
 384    The authors would like to acknowledge Emile Bergen, Alan DeKok, Greg
 385    Weber, Glen Zorn, Pasi Eronen, David Mitton, and David Nelson for
 386    contributions to this document.
 387
 388
 389
 390
 391
 392
 393
 394 Congdon, et al.             Standards Track                     [Page 7]
 395 \f
 396 RFC 4849                 Filter Rule Attribute                April 2007
 397
 398
 399 Authors' Addresses
 400
 401    Paul Congdon
 402    Hewlett Packard Company
 403    ProCurve Networking by HP
 404    8000 Foothills Blvd, M/S 5662
 405    Roseville, CA  95747
 406
 407    EMail: paul.congdon@hp.com
 408    Phone: +1 916 785 5753
 409    Fax:   +1 916 785 8478
 410
 411
 412    Mauricio Sanchez
 413    Hewlett Packard Company
 414    ProCurve Networking by HP
 415    8000 Foothills Blvd, M/S 5559
 416    Roseville, CA  95747
 417
 418    EMail: mauricio.sanchez@hp.com
 419    Phone: +1 916 785 1910
 420    Fax:   +1 916 785 1815
 421
 422
 423    Bernard Aboba
 424    Microsoft Corporation
 425    One Microsoft Way
 426    Redmond, WA 98052
 427
 428    EMail: bernarda@microsoft.com
 429    Phone: +1 425 706 6605
 430    Fax:   +1 425 936 7329
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450 Congdon, et al.             Standards Track                     [Page 8]
 451 \f
 452 RFC 4849                 Filter Rule Attribute                April 2007
 453
 454
 455 Full Copyright Statement
 456
 457    Copyright (C) The IETF Trust (2007).
 458
 459    This document is subject to the rights, licenses and restrictions
 460    contained in BCP 78, and except as set forth therein, the authors
 461    retain all their rights.
 462
 463    This document and the information contained herein are provided on an
 464    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 465    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 466    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 467    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 468    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 469    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 470
 471 Intellectual Property
 472
 473    The IETF takes no position regarding the validity or scope of any
 474    Intellectual Property Rights or other rights that might be claimed to
 475    pertain to the implementation or use of the technology described in
 476    this document or the extent to which any license under such rights
 477    might or might not be available; nor does it represent that it has
 478    made any independent effort to identify any such rights.  Information
 479    on the procedures with respect to rights in RFC documents can be
 480    found in BCP 78 and BCP 79.
 481
 482    Copies of IPR disclosures made to the IETF Secretariat and any
 483    assurances of licenses to be made available, or the result of an
 484    attempt made to obtain a general license or permission for the use of
 485    such proprietary rights by implementers or users of this
 486    specification can be obtained from the IETF on-line IPR repository at
 487    http://www.ietf.org/ipr.
 488
 489    The IETF invites any interested party to bring to its attention any
 490    copyrights, patents or patent applications, or other proprietary
 491    rights that may cover technology that may be required to implement
 492    this standard.  Please address the information to the IETF at
 493    ietf-ipr@ietf.org.
 494
 495 Acknowledgement
 496
 497    Funding for the RFC Editor function is currently provided by the
 498    Internet Society.
 499
 500
 501
 502
 503
 504
 505
 506 Congdon, et al.             Standards Track                     [Page 9]
 507 \f