idnits 2.17.1 draft-calhoun-diameter-authent-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 59 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 59 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 127: '... MUST This word, or the adject...' RFC 2119 keyword, line 131: '... MUST NOT This phrase means that t...' RFC 2119 keyword, line 134: '... SHOULD This word, or the adject...' RFC 2119 keyword, line 140: '... MAY This word, or the adject...' RFC 2119 keyword, line 142: '...hich does not include this option MUST...' (192 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '11' is defined on line 2708, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2138 (ref. '1') (Obsoleted by RFC 2865) == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-03 -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-12) exists of draft-ietf-roamops-nai-10 -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: A later version (-03) exists of draft-calhoun-diameter-eap-01 -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 1717 (ref. '9') (Obsoleted by RFC 1990) == Outdated reference: A later version (-08) exists of draft-calhoun-diameter-res-mgmt-01 -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-framework-00 -- Possible downref: Normative reference to a draft: ref. '11' Summary: 13 errors (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Pat R. Calhoun 3 Category: Standards Track Sun Microsystems, Inc. 4 Title: draft-calhoun-diameter-authent-03.txt William Bulley 5 Date: May 1998 Merit Network, Inc. 7 DIAMETER 8 User Authentication Extensions 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months. Internet-Drafts may be updated, replaced, or obsoleted by 20 other documents at any time. It is not appropriate to use Internet- 21 Drafts as reference material or to cite them other than as a 22 ``working draft'' or ``work in progress.'' 24 To view the entire list of current Internet-Drafts, please check 25 the "1id-abstracts.txt" listing contained in the Internet-Drafts 26 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 27 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 28 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 29 (US West Coast). 31 Abstract 33 DIAMETER is a Policy and AAA protocol which can be used for a variety 34 of services. This document defines DIAMETER messages that are used 35 for the authentication, authorization and accounting of users. 37 A considerable amount of effort was put into the design of this 38 protocol to ensure that an implementation could support both DIAMETER 39 and RADIUS concurrently. 41 Table of Contents 43 1.0 Introduction 44 1.1 Specification of Requirements 45 2.0 Command Codes 46 2.1 Domain-Discovery-Request 47 2.2 Domain-Discovery-Response 48 2.3 Access-Request 49 2.4 Access-Response 50 2.5 Access-Challenge 51 3.0 DIAMETER AVPs 52 3.1 User-Name 53 3.2 User-Password 54 3.3 CHAP-Password 55 3.4 NAS-Port 56 3.5 Service-Type 57 3.6 Framed-Protocol 58 3.7 Framed-IP-Address 59 3.8 Framed-IP-Netmask 60 3.9 Framed-Routing 61 3.10 Filter-Id 62 3.11 Framed-MTU 63 3.12 Framed-Compression 64 3.13 Login-IP-Host 65 3.14 Login-Service 66 3.15 Login-TCP-Port 67 3.16 Reply-Message 68 3.17 Callback-Number 69 3.18 Callback-Id 70 3.19 Framed-Route 71 3.20 Framed-IPX-Network 72 3.21 State 73 3.22 Class 74 3.23 Vendor-Specific 75 3.24 Session-Timeout 76 3.25 Idle-Timeout 77 3.26 Termination-Action 78 3.27 Called-Station-Id 79 3.28 Calling-Station-Id 80 3.29 Proxy-State 81 3.30 Login-LAT-Service 82 3.31 Login-LAT-Node 83 3.32 Login-LAT-Group 84 3.33 Framed-AppleTalk-Link 85 3.34 Framed-AppleTalk-Network 86 3.35 Framed-AppleTalk-Zone 87 3.36 CHAP-Challenge 88 3.37 NAS-Port-Type 89 3.38 Port-Limit 90 3.39 Login-LAT-Port 91 3.40 Filter-Rule 92 3.41 Framed-Password-Policy 93 3.42 Table of Attributes 94 4.0 Protocol Definition 95 4.1 Authorization Procedure 96 4.2 Integration with Resource-Management 97 4.3 RADIUS Proxies 98 4.4 DIAMETER Proxies 99 4.5 Domain Discovery 100 5.0 References 101 6.0 Acknowledgements 102 7.0 Authors' Addresses 104 1.0 Introduction 106 This document describes the DIAMETER User Authentication Extensions 107 that can be used for a variety of services including Dial-up users 108 via NAS, WWW User Authentication, Firewall User Authentication[5][6]. 110 This document describes Authentication/Authorization messages as well 111 as a set of messages which allow DIAMETER hosts to bypass proxies. 113 Since Most of the AVPs found in this document was copied from the 114 RADIUS protocol[1], it is possible to have both RADIUS and DIAMETER 115 servers read the same dictionary and users files. The backward 116 compatibility that DIAMETER offers is intended to facilitate 117 deployment. 119 The Extension number for this draft is one. This value is used in the 120 Service-Id AVP as defined in [2]. 122 1.1 Specification of Requirements 124 In this document, several words are used to signify the requirements 125 of the specification. These words are often capitalized. 127 MUST This word, or the adjective "required", means that the 128 definition is an absolute requirement of the 129 specification. 131 MUST NOT This phrase means that the definition is an absolute 132 prohibition of the specification. 134 SHOULD This word, or the adjective "recommended", means that 135 there may exist valid reasons in particular circumstances 136 to ignore this item, but the full implications must be 137 understood and carefully weighed before choosing a 138 different course. 140 MAY This word, or the adjective "optional", means that this 141 item is one of an allowed set of alternatives. An 142 implementation which does not include this option MUST 143 be prepared to interoperate with another implementation 144 which does include the option. 146 2.0 Command Codes 148 This document defines the following DIAMETER Commands. All DIAMETER 149 implementations supporting this extension MUST support all of the 150 following commands: 152 Command Name Command Code 153 ----------------------------------- 154 Domain-Discovery-Request 261 155 Domain-Discovery-Response 262 156 Access-Request 263 157 Access-Response 264 158 Access-Challenge 265 160 2.1 Domain-Discovery-Request 162 Description 164 The Domain-Discovery-Request message is used by a DIAMETER device 165 wishing to get contact information about a domain's home 166 authentication server as well as to receive password policy 167 information. This message MUST contain the User-Name attribute in 168 order to pass along the user's domain information. 170 The X509-Certificate or the X509-Certificate-URL [2] MUST be 171 present in this message in order to inform the home authentication 172 server of the issuing host's certificate. 174 A summary of the Domain-Discovery-Request packet format is shown 175 below. The fields are transmitted from left to right. 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | AVP Code | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | AVP Length | AVP Flags | Reserved | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Command Code | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 Code 189 256 DIAMETER Command 191 AVP Length 193 The length of this attribute MUST be 12. 195 AVP Flags 197 The AVP Flags field MUST have bit one (Mandatory Support) set. 199 Command Type 201 The Command Type field MUST be set to 261 (Domain-Discovery- 202 Request). 204 2.2 Domain-Discovery-Response 206 Description 208 The Domain-Discovery-Response message is sent in response to the 209 Domain-Discovery-Request message by the domain's Home 210 authentication server. The message MUST contain either the Host- 211 Name or Host-IP-Address and either the X509-Certificate or the 212 X509-Certificate-URL attribute and SHOULD contain at least one 213 Framed-Password-Policy AVP. 215 The absence of any Framed-Password-Policy AVPs means that the 216 issuer will only accept CHAP and PAP. 218 The Domain-Discovery-Response message MUST include the Result-Code 219 AVP to indicate whether the request was successful or not. The 220 following Error Codes are defined for this command: 222 DIAMETER_ERROR_UNKNOWN_DOMAIN 1 223 This error code is used to indicate to the initiator of the 224 request that the requested domain is unknown and cannot be 225 resolved. 227 DIAMETER_ERROR_BAD_CERT 2 228 This error code is used to indicate that the X509- 229 Certificate or the X509-Certificate-URL in the Domain- 230 Discovery-Request was invalid. 232 DIAMETER_ERROR_CANNOT_REPLY 3 233 This error code is returned when either an intermediate 234 DIAMETER node or the home authentication server cannot reply 235 to DIAMETER messages directly. This could be that the 236 policy of an intermediate DIAMETER server does not permit 237 direct contact and therefore requires proxying. It could 238 also signify that the home authentication server does not 239 have public key support. 241 A summary of the Domain-Discovery-Response packet format is shown 242 below. The fields are transmitted from left to right. 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | AVP Code | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | AVP Length | AVP Flags | Reserved | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Command Code | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Code 256 256 DIAMETER Command 258 AVP Length 260 The length of this attribute MUST be 12. 262 AVP Flags 264 The AVP Flags field MUST have bit one (Mandatory Support) set. 266 Command Type 268 The Command Type field MUST be set to 262 (Domain-Discovery- 269 Response). 271 2.3 Access-Request 273 Description 274 The Access-Request message is used in order to request 275 authentication and authorization for a given user. 277 If Authentication is requested the User-Name attribute MUST be 278 present. If only Authorization is required it is possible to 279 authorize based on DNIS and ANI instead. However, it is not 280 possible to authenticate using a User-Name AVP and later 281 requesting authorization based on DNIS using the same Session-Id 282 (although the inverse is legal). 284 Note that the flag field MAY be used in this command in order to 285 indicate that either Authentication-Only or Authorization-Only is 286 required for the request. If the Authentication-Only bit is set 287 the response MUST NOT include any authorization information. Both 288 the Authenticate and Authorize bits MUST NOT be set at the same 289 time. To ensure that a user is both authenticated and authorized, 290 neither flag is set. 292 The Access-Request message MUST include a unique Session-Id AVP. 293 If The Access-Request is a result of a successful Access-Challenge 294 the Session-Id MUST be identical to the one provided in the 295 initial Access-Request. 297 A summary of the Access-Request packet format is shown below. The 298 fields are transmitted from left to right. 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | AVP Code | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | AVP Length | AVP Flags | Reserved | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Command Code | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Code 312 256 DIAMETER Command 314 AVP Length 316 The length of this attribute MUST be 12. 318 AVP Flags 320 The AVP Flags field MUST have bit one (Mandatory Support) set. In 321 addition, the following bits may be used (note these bits are 322 mutually exclusive): 324 Authenticate-Only 32 325 The Authentication-Only bit is set to indicate that only 326 authentication of the user is requested and that no 327 authorization information should be returned in the 328 response. 330 Authorize-Only 64 331 The Authorization-Only bit is set to indicate that only 332 authorization of the user is requested and that no 333 authentication is required. 335 Command Type 337 The Command Type field MUST be set to 263 (Access-Request). 339 2.4 Access-Response 341 Description 343 The Access-Response message is used in order to indicate that 344 Authentication and/or authorization was successful. If 345 authorization was requested a list of AVPs with the authorization 346 information MUST be attached to the message (see section 3.41). 348 The Access-Response message MUST include the Session-Id AVP that 349 was present in the Access-Request. The Access-Response MUST also 350 include the Host-Name AVP and the Result-Code AVP to indicate the 351 status of the session. The following error codes are defined for 352 this message: 354 DIAMETER_ERROR_UNKNOWN_DOMAIN 1 355 This error code is used to indicate to the initiator of the 356 request that the requested domain is unknown and cannot be 357 resolved. 359 DIAMETER_ERROR_USER_UNKNOWN 2 360 This error code is used to indicate to the initiator that 361 the username request is not valid. 363 DIAMETER_ERROR_BAD_PASSWORD 3 364 This error code indicates that the password provided is 365 invalid. 367 DIAMETER_ERROR_CANNOT_AUTHORIZE 4 368 This error code is used to indicate that the user cannot be 369 authorized due to the fact that the user has expended the 370 servers local resources. This could be a result that the 371 server believes that the user already has an active session, 372 or that the user has already spent the number of credits in 373 his/her account, etc. 375 Note that the flag field MUST be set to the same value that was 376 found in the Access-Request message. 378 A summary of the Access-Response packet format is shown below. The 379 fields are transmitted from left to right. 381 0 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | AVP Code | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | AVP Length | AVP Flags | Reserved | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Command Code | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 Code 393 256 DIAMETER Command 395 AVP Length 397 The length of this attribute MUST be 12. 399 AVP Flags 401 The AVP Flags field MUST have bit one (Mandatory Support) set. In 402 addition, the following bits may be used (note these bits are 403 mutually exclusive): 405 Authenticate-Only 32 406 The Authentication-Only bit is set to indicate that only 407 authentication of the user is requested and that no 408 authorization information should be returned in the 409 response. 411 Authorize-Only 64 412 The Authorization-Only bit is set to indicate that only 413 authorization of the user is requested and that no 414 authentication is required. 416 Command Type 417 The Command Type field MUST be set to 264 (Access-Response). 419 2.5 Access-Challenge 421 Description 423 If the DIAMETER server desires to send the user a challenge 424 requiring a response, then the DIAMETER server MUST respond to the 425 Access-Request by transmitting a packet with the Code field set to 426 265 (Access-Challenge). 428 The message MAY have one or more Reply-Message AVP, and MAY have a 429 single State AVP, or none. No other AVPs are permitted in an 430 Access-Challenge other than the Integrity-Check-Vector or 431 Digital-Signature AVP as defined in [2]. 433 On receipt of an Access-Challenge, the Identifier field is matched 434 with a pending Access-Request. Invalid packets are silently 435 discarded. 437 The receipt of a valid Access-Challenge indicates that a new 438 Access-Request SHOULD be sent. The NAS MAY display the text 439 message, if any, to the user, and then prompt the user for a 440 response. It then sends its original Acess-Request with a new 441 request ID, with the User-Password AVP replaced by the user's 442 response (encrypted), and including the State AVP from the 443 Access-Challenge, if any. Only zero or one instances of the State 444 Attribute can be present in an Access-Request. 446 A NAS which supports PAP MAY forward the Reply-Message to the 447 dialin client and accept a PAP response which it can use as though 448 the user had entered the response. If the NAS cannot do so, it 449 should treat the Access-Challenge as though it had received an 450 Access-Response with a Result-Code AVP set to a value other than 451 DIAMETER_SUCCESS instead. 453 It is preferable to use EAP [5] instead of the Access-Challenge, 454 yet it has been maintained for backward compatibility. 456 The Access-Response message MUST include the Session-Id AVP that 457 was present in the Access-Request and MUST include the same flag 458 value that was found in the Access-Request. 460 A summary of the Access-Challenge packet format is shown below. 461 The fields are transmitted from left to right. 463 0 1 2 3 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | AVP Code | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | AVP Length | AVP Flags | Reserved | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Command Code | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Code 475 256 DIAMETER Command 477 AVP Length 479 The length of this attribute MUST be 12. 481 AVP Flags 483 The AVP Flags field MUST have bit one (Mandatory Support) set. In 484 addition, following bits may be used (note these bits are mutually 485 exclusive): 487 Authenticate-Only 32 488 The Authentication-Only bit is set to indicate that only 489 authentication of the user is requested and that no 490 authorization information should be returned in the 491 response. 493 Authorize-Only 64 494 The Authorization-Only bit is set to indicate that only 495 authorization of the user is requested and that no 496 authentication is required. 498 Command Type 500 The Command Type field MUST be set to 265 (Access-Challenge). 502 3.0 DIAMETER AVPs 504 This section will define the mandatory AVPs which MUST be supported 505 by all DIAMETER implementations supporting this extension. The 506 following AVPs are defined in this document: 508 Attribute Name Attribute Code 509 ----------------------------------- 510 User-Name 1 511 User-Password 2 512 CHAP-Password 3 513 NAS-IP-Address 4 514 NAS-Port 5 515 Service-Type 6 516 Framed-Protocol 7 517 Framed-IP-Address 8 518 Framed-IP-Netmask 9 519 Framed-Routing 10 520 Filter-Id 11 521 Framed-MTU 12 522 Framed-Compression 13 523 Login-IP-Host 14 524 Login-Service 15 525 Login-TCP-Port 16 526 Reply-Message 18 527 Callback-Number 19 528 Callback-Id 20 529 Framed-Route 22 530 Framed-IPX-Network 23 531 State 24 532 Class 25 533 Vendor-Specific 26 534 Session-Timeout 27 535 Idle-Timeout 28 536 Termination-Action 29 537 Called-Station-Id 30 538 Calling-Station-Id 31 539 NAS-Identifier 32 540 Proxy-State 33 541 Login-LAT-Service 34 542 Login-LAT-Node 35 543 Login-LAT-Group 36 544 Framed-AppleTalk-Link 37 545 Framed-AppleTalk-Network 38 546 Framed-AppleTalk-Zone 39 547 CHAP-Challenge 60 548 NAS-Port-Type 61 549 Port-Limit 62 550 Login-LAT-Port 63 551 Filter-Rule 280 552 Framed-Password-Policy 281 554 3.1 User-Name 556 Description 557 This Attribute indicates the name of the user to be authenticated. 558 It is normally used in Access-Request packets, but MAY be present 559 in the Access-Response message. 561 A summary of the User-Name Attribute format is shown below. The 562 fields are transmitted from left to right. 564 0 1 2 3 565 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 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | AVP Code | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | AVP Length | AVP Flags | Reserved | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | String ... 572 +-+-+-+-+-+-+-+-+ 574 Type 576 1 for User-Name. 578 AVP Length 580 The length of this attribute MUST be at least 9. 582 AVP Flags 584 The AVP Flags field MUST have bit one (Mandatory Support) set. The 585 SS-Encrypted-Data bit SHOULD be set if a shared secret exists. 586 The PK-Encrypted-data bit SHOULD NOT be set since intermediate 587 DIAMETER servers will require this information in order to 588 determine the home DIAMETER server. 590 String 592 The String field is one or more octets. All DIAMETER systems 593 SHOULD support User-Name lengths of at least 63 octets. The format 594 of the User-Name SHOULD follow the format defined in [3]. 596 3.2 User-Password 598 Description 600 This Attribute indicates the password of the user to be 601 authenticated, or the user's input following an Access-Challenge. 602 It is only used in Access-Request packets. 604 This AVP MUST be encrypted using one of the methods described in 605 [2]. The use of this AVP with shared secret encryption is strongly 606 discouraged by the author due to the security implications in a 607 proxy environment, yet the support of this attribute has been 608 retained for RADIUS backward compability. 610 A summary of the User-Password Attribute format is shown below. 611 The fields are transmitted from left to right. 613 0 1 2 3 614 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 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | AVP Code | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | AVP Length | AVP Flags | Reserved | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Data ... 621 +-+-+-+-+-+-+-+-+ 623 Type 625 2 for User-Password. 627 AVP Length 629 The length of this attribute MUST be at least 24 and MUST be no 630 larger than 136. 632 AVP Flags 634 The AVP Flags field MUST have bit one (Mandatory Support) set. One 635 of the AVP Encryption bits MUST be set. 637 Data 639 The Data field is between 16 and 128 octets long, inclusive. 641 3.3 CHAP-Password 643 Description 645 This Attribute indicates the response value provided by a PPP 646 Challenge-Handshake Authentication Protocol (CHAP) user in 647 response to the challenge. It is only used in Access-Request 648 packets. 650 If the CHAP-Password Attribute is found in a message, the CHAP- 651 Challenge Attribute (60) MUST be present as well. 653 A summary of the CHAP-Password Attribute format is shown below. 654 The fields are transmitted from left to right. 656 0 1 2 3 657 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 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | AVP Code | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | AVP Length | AVP Flags | Reserved | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | CHAP Ident | Data ... 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 Type 668 3 for CHAP-Password. 670 AVP Length 672 The length of this attribute MUST be 25. 674 AVP Flags 676 The AVP Flags field MUST have bit one (Mandatory Support) set. 678 CHAP Ident 680 This field is one octet, and contains the CHAP Identifier from the 681 user's CHAP Response. 683 Data 685 The Data field is 16 octets, and contains the CHAP Response from 686 the user. 688 3.4 NAS-Port 690 Description 692 This Attribute indicates the physical port number of the NAS which 693 is authenticating the user. It is normally only used in Access- 694 Request messages (see section x for more info). Note that this is 695 using "port" in its sense of a physical connection on the NAS, not 696 in the sense of a TCP or UDP port number. Either NAS-Port or NAS- 697 Port-Type (61) or both SHOULD be present in an Access-Request 698 packet, if the NAS differentiates among its ports. 700 A summary of the NAS-Port Attribute format is shown below. The 701 fields are transmitted from left to right. 703 0 1 2 3 704 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 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | AVP Code | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | AVP Length | AVP Flags | Reserved | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Integer32 | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 Type 715 5 for NAS-Port. 717 AVP Length 719 The length of this attribute MUST be 12. 721 AVP Flags 723 The AVP Flags field MUST have bit one (Mandatory Support) set. 725 Integer32 727 The Integer32 field is four octets. 729 3.5 Service-Type 731 Description 733 This Attribute indicates the type of service the user has 734 requested, or the type of service to be provided. It MAY be used 735 in both Access-Request and Access-Response messages. A NAS is not 736 required to implement all of these service types, and MUST treat 737 unknown or unsupported Service-Types as though an Access-Response 738 with a Result-Code other than DIAMETER-SUCCESS had been received 739 instead. 741 A summary of the Service-Type Attribute format is shown below. The 742 fields are transmitted from left to right. 744 0 1 2 3 745 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 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | AVP Code | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | AVP Length | AVP Flags | Reserved | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Integer32 | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 Type 756 6 for Service-Type. 758 AVP Flags 760 The AVP Flags field MUST have bit one (Mandatory Support) set. 762 AVP Length 764 The length of this attribute MUST be 12. 766 Integer32 768 The Integer32 field is four octets. 770 1 Login 771 2 Framed 772 3 Callback Login 773 4 Callback Framed 774 5 Outbound 775 6 Administrative 776 7 NAS Prompt 777 8 Authenticate Only 778 9 Callback NAS Prompt 780 The service types are defined as follows when used in an Access- 781 Response. When used in an Access-Request, they should be considered 782 to be a hint to the DIAMETER server that the NAS has reason to 783 believe the user would prefer the kind of service indicated, but the 784 server is not required to honor the hint. 786 Login The user should be connected to a host. 788 Framed A Framed Protocol should be started for the 789 User, such as PPP or SLIP. 791 Callback Login The user should be disconnected and called 792 back, then connected to a host. 794 Callback Framed The user should be disconnected and called 795 back, then a Framed Protocol should be started 796 for the User, such as PPP or SLIP. 798 Outbound The user should be granted access to outgoing 799 devices. 801 Administrative The user should be granted access to the 802 administrative interface to the NAS from which 803 privileged commands can be executed. 805 NAS Prompt The user should be provided a command prompt 806 on the NAS from which non-privileged commands 807 can be executed. 809 Authenticate Only Only Authentication is requested, and no 810 authorization information needs to be returned 811 in the Access-Response (typically used by 812 proxy servers rather than the NAS itself). This 813 SHOULD NOT be used in DIAMETER, yet it is 814 maintained for backward compatibility. 816 Callback NAS Prompt The user should be disconnected and called 817 back, then provided a command prompt on the 818 NAS from which non-privileged commands can be 819 executed. 821 3.6 Framed-Protocol 823 Description 825 This Attribute indicates the framing to be used for framed access. 826 It MAY be used in both Access-Request and Access-Response 827 messages. 829 A summary of the Framed-Protocol Attribute format is shown below. 830 The fields are transmitted from left to right. 832 0 1 2 3 833 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 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | AVP Code | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | AVP Length | AVP Flags | Reserved | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Integer32 | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 Type 844 7 for Framed-Protocol. 846 AVP Length 848 The length of this attribute MUST be 12. 850 AVP Flags 852 The AVP Flags field MUST have bit one (Mandatory Support) set. 854 Integer32 856 The Integer32 field is four octets. 858 1 PPP 859 2 SLIP 860 3 AppleTalk Remote Access Protocol (ARAP) 861 4 Gandalf proprietary SingleLink/MultiLink protocol 862 5 Xylogics proprietary IPX/SLIP 864 3.7 Framed-IP-Address 866 Description 868 This Attribute indicates the address to be configured for the 869 user. It MAY be used in Access-Request messages as a hint by the 870 NAS to the server that it would prefer that address, but the 871 server is not required to honor the hint. 873 A summary of the Framed-IP-Address Attribute format is shown 874 below. The fields are transmitted from left to right. 876 0 1 2 3 877 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 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | AVP Code | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | AVP Length | AVP Flags | Reserved | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | Address | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 Type 888 8 for Framed-IP-Address. 890 AVP Length 892 The length of this attribute MUST be 12. 894 AVP Flags 896 The AVP Flags field MUST have bit one (Mandatory Support) set. 898 Address 900 The Address field is four octets. The value 0xFFFFFFFF indicates 901 that the NAS should allow the user to select an address (e.g. 902 Negotiated). The value 0xFFFFFFFE indicates that the NAS should 903 select an address for the user (e.g. Assigned from a pool of 904 addresses kept by the NAS). Other valid values indicate that the 905 NAS should use that value as the user's IP address. 907 3.8 Framed-IP-Netmask 909 Description 911 This Attribute indicates the IP netmask to be configured for the 912 user when the user is a router to a network. It MUST be used in 913 Access-Response messages if the Framed-IP-Address AVP was returned 914 with a value other than 0xFFFFFFFF. It MAY be used in an Access- 915 Request message as a hint by the NAS to the server that it would 916 prefer that netmask, but the server is not required to honor the 917 hint. 919 A summary of the Framed-IP-Netmask Attribute format is shown 920 below. The fields are transmitted from left to right. 922 0 1 2 3 923 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 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 | AVP Code | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | AVP Length | AVP Flags | Reserved | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | Address | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 Type 934 9 for Framed-IP-Netmask. 936 AVP Length 937 The length of this attribute MUST be 12. 939 AVP Flags 941 The AVP Flags field MUST have bit one (Mandatory Support) set. 943 Address 945 The Address field is four octets specifying the IP netmask of the 946 user. 948 3.9 Framed-Routing 950 Description 952 This Attribute indicates the routing method for the user, when the 953 user is a router to a network. It is only used in Access-Response 954 messages. 956 A summary of the Framed-Routing Attribute format is shown below. 957 The fields are transmitted from left to right. 959 0 1 2 3 960 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 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 | AVP Code | 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | AVP Length | AVP Flags | Reserved | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | Integer32 | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 Type 971 10 for Framed-Routing. 973 AVP Length 975 The length of this attribute MUST be 12. 977 AVP Flags 979 The AVP Flags field MUST have bit one (Mandatory Support) set. 981 Integer32 983 The Integer32 field is four octets. 985 0 None 986 1 Send routing packets 987 2 Listen for routing packets 988 3 Send and Listen 990 3.10 Filter-Id 992 Description 994 This Attribute indicates the name of the filter list for this 995 user. Zero or more Filter-Id attributes MAY be sent in an Access- 996 Response message. 998 Identifying a filter list by name allows the filter to be used on 999 different NASes without regard to filter-list implementation 1000 details. However, this AVP is not roaming friendly since filter 1001 naming differs from one service provider to another. 1003 It is strongly encouraged to support the Filter-Rule AVP instead. 1005 A summary of the Filter-Id Attribute format is shown below. The 1006 fields are transmitted from left to right. 1008 0 1 2 3 1009 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 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | AVP Code | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | AVP Length | AVP Flags | Reserved | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | String ... 1016 +-+-+-+-+-+-+-+-+ 1018 Type 1020 11 for Filter-Id. 1022 AVP Length 1024 The length of this attribute MUST be at least 9. 1026 AVP Flags 1028 The AVP Flags field MUST have bit one (Mandatory Support) set. 1030 String 1031 The String field is one or more octets, and its contents are 1032 implementation dependent. It is intended to be human readable and 1033 MUST NOT affect operation of the protocol. It is recommended that 1034 the message contain displayable ASCII characters from the range 32 1035 through 126 decimal. 1037 3.11 Framed-MTU 1039 Description 1041 This Attribute indicates the Maximum Transmission Unit to be 1042 configured for the user, when it is not negotiated by some other 1043 means (such as PPP). It is only used in Access-Response messages. 1045 A summary of the Framed-MTU Attribute format is shown below. The 1046 fields are transmitted from left to right. 1048 0 1 2 3 1049 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 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | AVP Code | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | AVP Length | AVP Flags | Reserved | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | Integer32 | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 Type 1060 12 for Framed-MTU. 1062 AVP Length 1064 The length of this attribute MUST be 12. 1066 AVP Flags 1068 The AVP Flags field MUST have bit one (Mandatory Support) set. 1070 Integer32 1072 The Integer32 field is four octets. Despite the size of the field, 1073 values range from 64 to 65535. 1075 3.12 Framed-Compression 1076 Description 1078 This Attribute indicates a compression protocol to be used for the 1079 link. It MAY be used in Access-Response packets. It MAY be used in 1080 an Access-Request packet as a hint to the server that the NAS 1081 would prefer to use that compression, but the server is not 1082 required to honor the hint. 1084 More than one compression protocol Attribute MAY be sent. It is 1085 the responsibility of the NAS to apply the proper compression 1086 protocol to appropriate link traffic. 1088 A summary of the Framed-Compression Attribute format is shown 1089 below. The fields are transmitted from left to right. 1091 0 1 2 3 1092 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 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | AVP Code | 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 | AVP Length | AVP Flags | Reserved | 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 | Integer32 | 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 Type 1103 13 for Framed-Compression. 1105 AVP Length 1107 The length of this attribute MUST be 12. 1109 AVP Flags 1111 The AVP Flags field MUST have bit one (Mandatory Support) set. 1113 Integer32 1115 The Integer32 field is four octets. 1117 0 None 1118 1 VJ TCP/IP header compression [7] 1119 2 IPX header compression 1121 3.13 Login-IP-Host 1122 Description 1124 This Attribute indicates the system with which to connect the 1125 user, when the Login-Service Attribute is included. It MAY be used 1126 in Access-Response messages. It MAY be used in an Access-Request 1127 message as a hint to the server that the NAS would prefer to use 1128 that host, but the server is not required to honor the hint. 1130 A summary of the Login-IP-Host Attribute format is shown below. 1131 The fields are transmitted from left to right. 1133 0 1 2 3 1134 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 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 | AVP Code | 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 | AVP Length | AVP Flags | Reserved | 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 | Address | 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 Type 1145 14 for Login-IP-Host. 1147 AVP Length 1149 The length of this attribute MUST be 12. 1151 AVP Flags 1153 The AVP Flags field MUST have bit one (Mandatory Support) set. 1155 Address 1157 The Address field is four octets. The value 0xFFFFFFFF indicates 1158 that the NAS SHOULD allow the user to select an address. The value 1159 zero indicates that the NAS SHOULD select a host to connect the 1160 user to. Other values indicate the address the NAS SHOULD connect 1161 the user to. 1163 3.14 Login-Service 1165 Description 1167 This Attribute indicates the service which should be used to 1168 connect the user to the login host. It is only used in Access- 1169 Response messages. 1171 A summary of the Login-Service Attribute format is shown below. 1172 The fields are transmitted from left to right. 1174 0 1 2 3 1175 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 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 | AVP Code | 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 | AVP Length | AVP Flags | Reserved | 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1181 | Integer32 | 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 Type 1186 15 for Login-Service. 1188 AVP Length 1190 The length of this attribute MUST be 12. 1192 AVP Flags 1194 The AVP Flags field MUST have bit one (Mandatory Support) set. 1196 Integer32 1198 The Integer32 field is four octets. 1200 0 Telnet 1201 1 Rlogin 1202 2 TCP Clear 1203 3 PortMaster (proprietary) 1204 4 LAT 1206 3.15 Login-TCP-Port 1208 Description 1210 This Attribute indicates the TCP port with which the user is to be 1211 connected, when the Login-Service Attribute is also present. It is 1212 only used in Access-Response packets. 1214 A summary of the Login-TCP-Port Attribute format is shown below. 1215 The fields are transmitted from left to right. 1217 0 1 2 3 1218 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 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 | AVP Code | 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 | AVP Length | AVP Flags | Reserved | 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 | Integer32 | 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1227 Type 1229 16 for Login-TCP-Port. 1231 AVP Length 1233 The length of this attribute MUST be 12. 1235 AVP Flags 1237 The AVP Flags field MUST have bit one (Mandatory Support) set. 1239 Integer32 1241 The Integer32 field is four octets. Despite the size of the field, 1242 values range from zero to 65535. 1244 3.16 Reply-Message 1246 Description 1248 This Attribute indicates text which MAY be displayed to the user. 1250 When used in an Access-Response message with a successful Result- 1251 Code AVP it indicates the success message. When found in the same 1252 message with a Result-Code other than DIAMETER-SUCCESS it contains 1253 the failure message. 1255 It MAY indicate a dialog message to prompt the user before another 1256 Access-Request attempt. 1258 When used in an Access-Challenge, it MAY indicate a dialog message 1259 to prompt the user for a response. 1261 Multiple Reply-Message's MAY be included and if any are displayed, 1262 they MUST be displayed in the same order as they appear in the 1263 packet. 1265 A summary of the Reply-Message Attribute format is shown below. 1266 The fields are transmitted from left to right. 1268 0 1 2 3 1269 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 1270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 | AVP Code | 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 | AVP Length | AVP Flags | Reserved | 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 | String ... 1276 +-+-+-+-+-+-+-+-+ 1278 Type 1280 18 for Reply-Message. 1282 AVP Length 1284 The length of this attribute MUST be at least 9. 1286 AVP Flags 1288 The AVP Flags field MUST have bit one (Mandatory Support) set. 1290 String 1292 The String field is one or more octets, and its contents are 1293 implementation dependent. It is intended to be human readable, and 1294 MUST NOT affect operation of the protocol. It is recommended that 1295 the message contain displayable ASCII characters from the range 1296 10, 13, and 32 through 126 decimal. Mechanisms for extension to 1297 other character sets are beyond the scope of this specification. 1299 3.17 Callback-Number 1301 Description 1303 This Attribute indicates a dialing string to be used for callback. 1304 It MAY be used in Access-Response packets. It MAY be used in an 1305 Access-Request packet as a hint to the server that a Callback 1306 service is desired, but the server is not required to honor the 1307 hint. 1309 A summary of the Callback-Number Attribute format is shown below. 1310 The fields are transmitted from left to right. 1312 0 1 2 3 1313 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 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 | AVP Code | 1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1317 | AVP Length | AVP Flags | Reserved | 1318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1319 | String ... 1320 +-+-+-+-+-+-+-+-+ 1322 Type 1324 19 for Callback-Number. 1326 AVP Length 1328 The length of this attribute MUST be at least 9. 1330 AVP Flags 1332 The AVP Flags field MUST have bit one (Mandatory Support) set. 1334 String 1336 The String field is one or more octets. The actual format of the 1337 information is site or application specific, and a robust 1338 implementation SHOULD support the field as undistinguished octets. 1340 The codification of the range of allowed usage of this field is 1341 outside the scope of this specification. 1343 3.18 Callback-Id 1345 Description 1347 This Attribute indicates the name of a place to be called, to be 1348 interpreted by the NAS. It MAY be used in Access-Response 1349 messages. 1351 This AVP is not roaming friendly since it assumes that the 1352 Callback-Id is configured on the NAS. It is therefore preferable 1353 to use the Callback-Number AVP instead. 1355 A summary of the Callback-Id Attribute format is shown below. The 1356 fields are transmitted from left to right. 1358 0 1 2 3 1359 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 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 | AVP Code | 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 | AVP Length | AVP Flags | Reserved | 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1365 | String ... 1366 +-+-+-+-+-+-+-+-+ 1368 Type 1370 20 for Callback-Id. 1372 AVP Length 1374 The length of this attribute MUST be at least 9. 1376 AVP Flags 1378 The AVP Flags field MUST have bit one (Mandatory Support) set. 1380 String 1382 The String field is one or more octets. The actual format of the 1383 information is site or application specific, and a robust 1384 implementation SHOULD support the field as undistinguished octets. 1385 The codification of the range of allowed usage of this field is 1386 outside the scope of this specification. 1388 3.19 Framed-IP-Route 1390 Description 1392 This Attribute provides routing information to be configured for 1393 the user on the NAS. It is used in the Access-Response message and 1394 can appear multiple times. 1396 A summary of the Framed-Route Attribute format is shown below. The 1397 fields are transmitted from left to right. 1399 0 1 2 3 1400 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 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 | AVP Code | 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 | AVP Length | AVP Flags | Reserved | 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 | String ... 1407 +-+-+-+-+-+-+-+-+ 1409 Type 1411 22 for Framed-IP-Route. 1413 AVP Length 1415 The length of this attribute MUST be at least 9. 1417 AVP Flags 1419 The AVP Flags field MUST have bit one (Mandatory Support) set. 1421 String 1423 It MUST contain a destination prefix in dotted quad form 1424 optionally followed by a slash and a decimal length specifier 1425 stating how many high order bits of the prefix should be used. 1426 That is followed by a space, a gateway address in dotted quad 1427 form, a space, and one or more metrics separated by spaces. For 1428 example, "192.168.1.0/24 192.168.1.1 1". 1430 The length specifier may be omitted in which case it should 1431 default to 8 bits for class A prefixes, 16 bits for class B 1432 prefixes, and 24 bits for class C prefixes. For example, 1433 "192.168.1.0 192.168.1.1 1". 1435 Whenever the gateway address is specified as "0.0.0.0" the IP 1436 address of the user SHOULD be used as the gateway address. 1438 3.20 Framed-IPX-Network 1440 Description 1442 This Attribute indicates the IPX Network number to be configured 1443 for the user. It is used in Access-Response messages. 1445 A summary of the Framed-IPX-Network Attribute format is shown 1446 below. The fields are transmitted from left to right. 1448 0 1 2 3 1449 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 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 | AVP Code | 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 | AVP Length | AVP Flags | Reserved | 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 | Integer32 | 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 Type 1460 23 for Framed-IPX-Network. 1462 AVP Length 1464 The length of this attribute MUST be 12. 1466 AVP Flags 1468 The AVP Flags field MUST have bit one (Mandatory Support) set. 1470 Integer32 1472 The Integer32 field is four octets. The value 0xFFFFFFFF indicates 1473 that the NAS should allow the user to select an address (e.g. 1474 Negotiated). The value 0xFFFFFFFE indicates that the NAS should 1475 select an address for the user (e.g. assigned from a pool of one 1476 or more IPX networks kept by the NAS). Other values should be used 1477 as the IPX network for the link to the user. 1479 3.21 State 1481 Description 1483 This Attribute is available to be sent by the server to the client 1484 in an Access-Challenge and MUST be sent unmodified from the client 1485 to the server in the new Access-Request reply to that challenge, 1486 if any. 1488 In either usage, no interpretation by the client should be made. 1489 A packet may have only one State Attribute. Usage of the State 1490 Attribute is implementation dependent. 1492 A summary of the State Attribute format is shown below. The fields 1493 are transmitted from left to right. 1495 0 1 2 3 1496 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 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 | AVP Code | 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1500 | AVP Length | AVP Flags | Reserved | 1501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 | Data ... 1503 +-+-+-+-+-+-+-+-+ 1505 Type 1507 24 for State. 1509 AVP Length 1511 The length of this attribute MUST be at least 9. 1513 AVP Flags 1515 The AVP Flags field MUST have bit one (Mandatory Support) set. 1517 String 1519 The String field is one or more octets. The actual format of the 1520 information is site or application specific, and a robust 1521 implementation SHOULD support the field as undistinguished octets. 1523 The codification of the range of allowed usage of this field is 1524 outside the scope of this specification. 1526 3.22 Class 1528 Description 1530 This Attribute is available to be sent by the server to the client 1531 in an Access-Response and should be sent unmodified by the client 1532 to the accounting server as part of the Accounting-Request message 1533 if accounting is supported. No interpretation by the client should 1534 be made. 1536 A summary of the Class Attribute format is shown below. The fields 1537 are transmitted from left to right. 1539 0 1 2 3 1540 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 1541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1542 | AVP Code | 1543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1544 | AVP Length | AVP Flags | Reserved | 1545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 | Data ... 1548 +-+-+-+-+-+-+-+-+ 1550 Type 1552 25 for Class. 1554 AVP Length 1556 The length of this attribute MUST be at least 9. 1558 AVP Flags 1560 The AVP Flags field MUST have bit one (Mandatory Support) set. 1562 String 1564 The String field is one or more octets. The actual format of the 1565 information is site or application specific, and a robust 1566 implementation SHOULD support the field as undistinguished octets. 1568 The codification of the range of allowed usage of this field is 1569 outside the scope of this specification. 1571 3.23 Vendor-Specific 1573 Description 1575 This AVP is not supported in DIAMETER. Vendor Specific Attributes 1576 are used by enabling the Vendor-Specific bit in the AVP header. 1578 3.24 Session-Timeout 1580 Description 1582 This Attribute sets the maximum number of seconds of service to be 1583 provided to the user before termination of the session or prompt. 1584 This Attribute is available to be sent by the server to the client 1585 in an Access-Response or Access-Challenge. 1587 A summary of the Session-Timeout Attribute format is shown below. 1588 The fields are transmitted from left to right. 1590 0 1 2 3 1591 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 1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 | AVP Code | 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 | AVP Length | AVP Flags | Reserved | 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1597 | Integer32 | 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 Type 1602 27 for Session-Timeout. 1604 AVP Length 1606 The length of this attribute MUST be 12. 1608 AVP Flags 1610 The AVP Flags field MUST have bit one (Mandatory Support) set. 1612 Integer32 1614 The Integer32 field is 4 octets, containing a 32-bit unsigned 1615 integer with the maximum number of seconds this user should be 1616 allowed to remain connected by the NAS. 1618 A value of zero means that this session has an unlimited number of 1619 seconds before termination or prompt. 1621 3.25 Idle-Timeout 1623 Description 1625 This Attribute sets the maximum number of consecutive seconds of 1626 idle connection allowed to the user before termination of the 1627 session or prompt. This Attribute is available to be sent by the 1628 server to the client in an Access-Response or Access-Challenge. 1630 A summary of the Idle-Timeout Attribute format is shown below. The 1631 fields are transmitted from left to right. 1633 0 1 2 3 1634 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 1635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1636 | AVP Code | 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 | AVP Length | AVP Flags | Reserved | 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 | Integer32 | 1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1643 Type 1645 28 for Idle-Timeout. 1647 AVP Length 1649 The length of this attribute MUST be 12. 1651 AVP Flags 1653 The AVP Flags field MUST have bit one (Mandatory Support) set. 1655 Integer32 1657 The Integer32 field is 4 octets, containing a 32-bit unsigned 1658 integer with the maximum number of consecutive seconds of idle 1659 time this user should be permitted before being disconnected by 1660 the NAS. 1662 3.26. Termination-Action 1664 Description 1666 This Attribute is not supported in DIAMETER. 1668 3.27 Called-Station-Id 1670 Description 1672 This Attribute allows the NAS to send in the Access-Request 1673 message the phone number that the user called, using Dialed Number 1674 Identification (DNIS) or similar technology. Note that this may be 1675 different from the phone number the call comes in on. It is only 1676 used in Access-Request packets. 1678 If the Authorization-Only flag is set in the message and the 1679 User-Name AVP is absent, the DIAMETER Server MUST perform 1680 authorization based on this field. This can be used by a NAS to 1681 request whether a call should be answered based on the DNIS. 1683 A summary of the Called-Station-Id Attribute format is shown 1684 below. The fields are transmitted from left to right. 1686 0 1 2 3 1687 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 1688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1689 | AVP Code | 1690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1691 | AVP Length | AVP Flags | Reserved | 1692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1693 | String ... 1694 +-+-+-+-+-+-+-+-+ 1696 Type 1698 30 for Called-Station-Id. 1700 AVP Length 1702 The length of this attribute MUST be at least 9. 1704 AVP Flags 1706 The AVP Flags field MUST have bit one (Mandatory Support) set. 1708 String 1710 The String field is one or more octets, containing the phone 1711 number that the user's call came in on. 1713 The actual format of the information is site or application 1714 specific. Printable ASCII is recommended, but a robust 1715 implementation SHOULD support the field as undistinguished octets. 1717 The codification of the range of allowed usage of this field is 1718 outside the scope of this specification. 1720 3.28 Calling-Station-Id 1722 Description 1724 This Attribute allows the NAS to send in the Access-Request packet 1725 the phone number that the call came from, using Automatic Number 1726 Identification (ANI) or similar technology. It is only used in 1727 Access-Request packets. 1729 If the Authorization-Only flag is set in the message and the 1730 User-Name AVP is absent, the DIAMETER Server must perform 1731 authorization based on this field. This can be used by a NAS to 1732 request whether a call should be answered based on the ANI. 1734 A summary of the Calling-Station-Id Attribute format is shown 1735 below. The fields are transmitted from left to right. 1737 0 1 2 3 1738 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 1739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1740 | AVP Code | 1741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1742 | AVP Length | AVP Flags | Reserved | 1743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1744 | String ... 1745 +-+-+-+-+-+-+-+-+ 1747 Type 1749 31 for Calling-Station-Id. 1751 AVP Length 1753 The length of this attribute MUST be at least 9. 1755 AVP Flags 1757 The AVP Flags field MUST have bit one (Mandatory Support) set. 1759 String 1761 The String field is one or more octets, containing the phone 1762 number that the user placed the call from. 1764 The actual format of the information is site or application 1765 specific. Printable ASCII is recommended, but a robust 1766 implementation SHOULD support the field as undistinguished octets. 1768 The codification of the range of allowed usage of this field is 1769 outside the scope of this specification. 1771 3.29 Proxy-State 1773 Description 1775 This Attribute is available to be sent by a proxy server to 1776 another server when forwarding an Access-Request and MUST be 1777 returned unmodified in the Access-Response, or Access-Challenge. 1779 This attribute should be removed by the proxy server before the 1780 response is forwarded to the NAS, and SHOULD therefore not be 1781 protected by the Integrity-Check-Vector or the Digital-Signature. 1783 A summary of the Proxy-State Attribute format is shown below. The 1784 fields are transmitted from left to right. 1786 0 1 2 3 1787 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 1788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1789 | AVP Code | 1790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1791 | AVP Length | AVP Flags | Reserved | 1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1793 | Data ... 1794 +-+-+-+-+-+-+-+-+ 1796 Type 1798 33 for Proxy-State. 1800 AVP Length 1802 The length of this attribute MUST be at least 9. 1804 AVP Flags 1806 The AVP Flags field MUST have bit one (Mandatory Support) set. 1808 String 1810 The String field is one or more octets. The actual format of the 1811 information is site or application specific, and a robust 1812 implementation SHOULD support the field as undistinguished octets. 1814 The codification of the range of allowed usage of this field is 1815 outside the scope of this specification. 1817 3.30 Login-LAT-Service 1819 Description 1821 This Attribute indicates the system with which the user is to be 1822 connected by LAT. It MAY be used in Access-Response packets, but 1823 only when LAT is specified as the Login-Service. It MAY be used in 1824 an Access-Request packet as a hint to the server, but the server 1825 is not required to honor the hint. 1827 Administrators use the service attribute when dealing with 1828 clustered systems, such as a VAX or Alpha cluster. In such an 1829 environment several different time sharing hosts share the same 1830 resources (disks, printers, etc.), and administrators often 1831 configure each to offer access (service) to each of the shared 1832 resources. In this case, each host in the cluster advertises its 1833 services through LAT broadcasts. 1835 Sophisticated users often know which service providers (machines) 1836 are faster and tend to use a node name when initiating a LAT 1837 connection. Alternately, some administrators want particular users 1838 to use certain machines as a primitive form of load balancing 1839 (although LAT knows how to do load balancing itself). 1841 A summary of the Login-LAT-Service Attribute format is shown 1842 below. The fields are transmitted from left to right. 1844 0 1 2 3 1845 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 1846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1847 | AVP Code | 1848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1849 | AVP Length | AVP Flags | Reserved | 1850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1851 | String ... 1852 +-+-+-+-+-+-+-+-+ 1854 Type 1856 34 for Login-LAT-Service. 1858 AVP Length 1860 The length of this attribute MUST be at least 9. 1862 AVP Flags 1864 The AVP Flags field MUST have bit one (Mandatory Support) set. 1866 String 1868 The String field is one or more octets, and contains the identity 1869 of the LAT service to use. The LAT Architecture allows this string 1870 to contain $ (dollar), - (hyphen), . (period), _ (underscore), 1871 numerics, upper and lower case alphabetics, and the ISO Latin-1 1872 character set extension [8]. All LAT string comparisons are case 1873 insensitive. 1875 3.31 Login-LAT-Node 1877 Description 1878 This Attribute indicates the Node with which the user is to be 1879 automatically connected by LAT. It MAY be used in Access-Response 1880 packets, but only when LAT is specified as the Login-Service. It 1881 MAY be used in an Access-Request packet as a hint to the server, 1882 but the server is not required to honor the hint. 1884 A summary of the Login-LAT-Node Attribute format is shown below. 1885 The fields are transmitted from left to right. 1887 0 1 2 3 1888 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 1889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1890 | AVP Code | 1891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1892 | AVP Length | AVP Flags | Reserved | 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1894 | String ... 1895 +-+-+-+-+-+-+-+-+ 1897 Type 1899 35 for Login-LAT-Node. 1901 AVP Length 1903 The length of this attribute MUST be at least 9. 1905 AVP Flags 1907 The AVP Flags field MUST have bit one (Mandatory Support) set. 1909 String 1911 The String field is one or more octets, and contains the identity 1912 of the LAT Node to connect the user to. The LAT Architecture 1913 allows this string to contain $ (dollar), - (hyphen), . (period), 1914 _ (underscore), numerics, upper and lower case alphabetics, and 1915 the ISO Latin-1 character set extension. All LAT string 1916 comparisons are case insensitive. 1918 3.32 Login-LAT-Group 1920 Description 1922 This Attribute contains a string identifying the LAT group codes 1923 which this user is authorized to use. It MAY be used in Access- 1924 Response packets, but only when LAT is specified as the Login- 1925 Service. It MAY be used in an Access-Request packet as a hint to 1926 the server, but the server is not required to honor the hint. 1928 LAT supports 256 different group codes, which LAT uses as a form 1929 of access rights. LAT encodes the group codes as a 256 bit bitmap. 1931 Administrators can assign one or more of the group code bits at 1932 the LAT service provider; it will only accept LAT connections that 1933 have these group codes set in the bit map. The administrators 1934 assign a bitmap of authorized group codes to each user; LAT gets 1935 these from the operating system, and uses these in its requests to 1936 the service providers. 1938 A summary of the Login-LAT-Group Attribute format is shown below. 1939 The fields are transmitted from left to right. 1941 0 1 2 3 1942 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 1943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1944 | AVP Code | 1945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1946 | AVP Length | AVP Flags | Reserved | 1947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1948 | Data ... 1949 +-+-+-+-+-+-+-+-+ 1951 Type 1953 36 for Login-LAT-Group. 1955 AVP Length 1957 The length of this attribute MUST be 40. 1959 AVP Flags 1961 The AVP Flags field MUST have bit one (Mandatory Support) set. 1963 Data 1965 The Data field is a 32 octet bit map, most significant octet 1966 first. A robust implementation SHOULD support the field as 1967 undistinguished octets. 1969 The codification of the range of allowed usage of this field is 1970 outside the scope of this specification. 1972 3.33 Framed-AppleTalk-Link 1974 Description 1976 This Attribute indicates the AppleTalk network number which should 1977 be used for the serial link to the user, which is another 1978 AppleTalk router. It is only used in Access-Response packets. It 1979 is never used when the user is not another router. 1981 A summary of the Framed-AppleTalk-Link Attribute format is shown 1982 below. The fields are transmitted from left to right. 1984 0 1 2 3 1985 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 1986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1987 | AVP Code | 1988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1989 | AVP Length | AVP Flags | Reserved | 1990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1991 | Integer32 | 1992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1994 Type 1996 37 for Framed-AppleTalk-Link. 1998 AVP Length 2000 The length of this attribute MUST be 12. 2002 AVP Flags 2004 The AVP Flags field MUST have bit one (Mandatory Support) set. 2006 Integer32 2008 The Integer32 field is four octets. Despite the size of the field, 2009 values range from zero to 65535. The special value of zero 2010 indicates that this is an unnumbered serial link. A value of one 2011 to 65535 means that the serial line between the NAS and the user 2012 should be assigned that value as an AppleTalk network number. 2014 3.34 Framed-AppleTalk-Network 2016 Description 2018 This Attribute indicates the AppleTalk Network number which the 2019 NAS should probe to allocate an AppleTalk node for the user. It is 2020 only used in Access-Response packets. It is never used when the 2021 user is another router. Multiple instances of this Attribute 2022 indicate that the NAS may probe using any of the network numbers 2023 specified. 2025 A summary of the Framed-AppleTalk-Network Attribute format is 2026 shown below. The fields are transmitted from left to right. 2028 0 1 2 3 2029 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 2030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2031 | AVP Code | 2032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2033 | AVP Length | AVP Flags | Reserved | 2034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2035 | Integer32 | 2036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2038 Type 2040 38 for Framed-AppleTalk-Network. 2042 AVP Length 2044 The length of this attribute MUST be 12. 2046 AVP Flags 2048 The AVP Flags field MUST have bit one (Mandatory Support) set. 2050 Integer32 2052 The Integer32 field is four octets. Despite the size of the field, 2053 values range from zero to 65535. The special value zero indicates 2054 that the NAS should assign a network for the user, using its 2055 default cable range. A value between one and 65535 (inclusive) 2056 indicates the AppleTalk Network the NAS should probe to find an 2057 address for the user. 2059 3.35 Framed-AppleTalk-Zone 2061 Description 2063 This Attribute indicates the AppleTalk Default Zone to be used for 2064 this user. It is only used in Access-Response packets. Multiple 2065 instances of this attribute in the same packet are not allowed. 2067 A summary of the Framed-AppleTalk-Zone Attribute format is shown 2068 below. The fields are transmitted from left to right. 2070 0 1 2 3 2071 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 2072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2073 | AVP Code | 2074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2075 | AVP Length | AVP Flags | Reserved | 2076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2077 | Data ... 2078 +-+-+-+-+-+-+-+-+ 2080 Type 2082 39 for Framed-AppleTalk-Zone. 2084 AVP Length 2086 The length of this attribute MUST be at least 9. 2088 AVP Flags 2090 The AVP Flags field MUST have bit one (Mandatory Support) set. 2092 String 2094 The name of the Default AppleTalk Zone to be used for this user. 2095 A robust implementation SHOULD support the field as 2096 undistinguished octets. 2098 The codification of the range of allowed usage of this field is 2099 outside the scope of this specification. 2101 3.36 CHAP-Challenge 2103 Description 2105 This Attribute contains the CHAP Challenge sent by the NAS to a 2106 PPP Challenge-Handshake Authentication Protocol (CHAP) user. It is 2107 only used in Access-Request packets. 2109 A summary of the CHAP-Challenge Attribute format is shown below. 2110 The fields are transmitted from left to right. 2112 0 1 2 3 2113 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 2114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2115 | AVP Code | 2116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2117 | AVP Length | AVP Flags | Reserved | 2118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2119 | Data ... 2120 +-+-+-+-+-+-+-+-+ 2122 Type 2124 60 for CHAP-Challenge. 2126 AVP Length 2128 The length of this attribute MUST be at least 24. 2130 AVP Flags 2132 The AVP Flags field MUST have bit one (Mandatory Support) set. 2134 Data 2136 The Data field contains the CHAP Challenge. 2138 3.37 NAS-Port-Type 2140 Description 2142 This Attribute indicates the type of the physical port of the NAS 2143 which is authenticating the user. It can be used instead of or in 2144 addition to the NAS-Port (5) attribute. It is only used in 2145 Access-Request packets. Either NAS-Port (5) or NAS-Port-Type or 2146 both SHOULD be present in an Access-Request packet, if the NAS 2147 differentiates among its ports. 2149 A summary of the NAS-Port-Type Attribute format is shown below. 2150 The fields are transmitted from left to right. 2152 0 1 2 3 2153 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 2154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2155 | AVP Code | 2156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2157 | AVP Length | AVP Flags | Reserved | 2158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2159 | Integer32 | 2160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2162 Type 2164 61 for NAS-Port-Type. 2166 AVP Length 2168 The length of this attribute MUST be 12. 2170 AVP Flags 2172 The AVP Flags field MUST have bit one (Mandatory Support) set. 2174 Integer32 2176 The Integer32 field is four octets. "Virtual" refers to a 2177 connection to the NAS via some transport protocol, instead of 2178 through a physical port. For example, if a user telnetted into a 2179 NAS to authenticate himself as an Outbound-User, the Access- 2180 Request might include NAS-Port-Type = Virtual as a hint to the 2181 RADIUS server that the user was not on a physical port. 2183 0 Async 2184 1 Sync 2185 2 ISDN Sync 2186 3 ISDN Async V.120 2187 4 ISDN Async V.110 2188 5 Virtual 2190 3.38 Port-Limit 2192 Description 2194 This Attribute sets the maximum number of ports to be provided to 2195 the user by the NAS. This Attribute MAY be sent by the server to 2196 the client in an Access-Response packet. It is intended for use in 2197 conjunction with Multilink PPP [9] or similar uses. It MAY also be 2198 sent by the NAS to the server as a hint that that many ports are 2199 desired for use, but the server is not required to honor the hint. 2201 A summary of the Port-Limit Attribute format is shown below. The 2202 fields are transmitted from left to right. 2204 0 1 2 3 2205 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 2206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2207 | AVP Code | 2208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2209 | AVP Length | AVP Flags | Reserved | 2210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2211 | Integer32 | 2212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2214 Type 2216 62 for Port-Limit. 2218 AVP Length 2220 The length of this attribute MUST be 12. 2222 AVP Flags 2224 The AVP Flags field MUST have bit one (Mandatory Support) set. 2226 Integer32 2228 The Integer32 field is four octets, containing a 32-bit unsigned 2229 integer with the maximum number of ports this user should be 2230 allowed to connect to on the NAS. 2232 3.39 Login-LAT-Port 2234 Description 2236 This Attribute indicates the Port with which the user is to be 2237 connected by LAT. It MAY be used in Access-Response packets, but 2238 only when LAT is specified as the Login-Service. It MAY be used in 2239 an Access-Request packet as a hint to the server, but the server 2240 is not required to honor the hint. 2242 A summary of the Login-LAT-Port Attribute format is shown below. 2243 The fields are transmitted from left to right. 2245 0 1 2 3 2246 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 2247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2248 | AVP Code | 2249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2250 | AVP Length | AVP Flags | Reserved | 2251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2252 | String ... 2253 +-+-+-+-+-+-+-+-+ 2255 Type 2256 63 for Login-LAT-Port. 2258 AVP Length 2260 The length of this attribute MUST be at least 9. 2262 AVP Flags 2264 The AVP Flags field MUST have bit one (Mandatory Support) set. 2266 String 2268 The String field is one or more octets, and contains the identity 2269 of the LAT port to use. The LAT Architecture allows this string to 2270 contain $ (dollar), - (hyphen), . (period), _ (underscore), 2271 numerics, upper and lower case alphabetics, and the ISO Latin-1 2272 character set extension. All LAT string comparisons are case 2273 insensitive. 2275 3.40 Filter-Rule 2277 Description 2279 This Attribute provides filter rules that need to be configured on 2280 the NAS for the user. It is used in the Access-Response message 2281 and can appear multiple times. 2283 A summary of the Filter-Rule Attribute format is shown below. The 2284 fields are transmitted from left to right. 2286 0 1 2 3 2287 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 2288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2289 | AVP Code | 2290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2291 | AVP Length | AVP Flags | Reserved | 2292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2293 | String ... 2294 +-+-+-+-+-+-+-+-+ 2296 Type 2298 280 for Filter-Rule. 2300 AVP Length 2302 The length of this attribute MUST be at least 9. 2304 AVP Flags 2306 The AVP Flags field MUST have bit one (Mandatory Support) set. 2308 String 2310 The String field MUST contain a filter rule in the following 2311 format: "permit (offset=value AND offset=value) OR offset=value" 2312 or "deny (offset=value AND offset=value) OR offset=value". 2314 3.41 Framed-Password-Policy 2316 Description 2318 This Attribute is used to indicate to a peer what types of 2319 authentication are supported by the issuing DIAMETER peer. More 2320 than one Framed-Password-Policy AVP MAY be present in the Domain- 2321 Discovery-Response message. 2323 A summary of the User-Name Attribute format is shown below. The 2324 fields are transmitted from left to right. 2326 0 1 2 3 2327 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 2328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2329 | AVP Code | 2330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2331 | AVP Length | AVP Flags | Reserved | 2332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2333 | Integer32 | 2334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2336 Type 2338 281 for Framed-Password-Policy. 2340 AVP Length 2342 The length of this attribute MUST be 12. 2344 AVP Flags 2346 The AVP Flags field MUST have bit one (Mandatory Support) set. 2348 Integer32 2350 The Integer32 field contains the supported authentication schemes 2351 supported. The following values are supported: 2353 PAP 1 2354 CHAP 2 2355 MS-CHAP 3 2356 EAP 4 2357 SPAP 5 2359 3.42 Table of Attributes 2361 The following table provides a guide to which attributes may be found 2362 in which kinds of packets, and in what quantity. 2364 Req Succ Fail Chal Disc-Req Disc-Rsp # Attribute 2365 0-1 0-1 0 0 1 0-1 1 User-Name 2366 0-1 0 0 0 0 0 2 User-Password [*1] 2367 0-1 0 0 0 0 0 3 CHAP-Password [*1] 2368 0-1 0 0 0 0 0 4 NAS-IP-Address 2369 0-1 0 0 0 0 0 5 NAS-Port 2370 0-1 0-1 0 0 0 0 6 Service-Type 2371 0-1 0-1 0 0 0 0 7 Framed-Protocol 2372 0-1 0-1 0 0 0 0 8 Framed-IP-Address 2373 0-1 0-1 0 0 0 0 9 Framed-IP-Netmask 2374 0 0-1 0 0 0 0 10 Framed-Routing 2375 0 0+ 0 0 0 0 11 Filter-Id 2376 0 0-1 0 0 0 0 12 Framed-MTU 2377 0+ 0+ 0 0 0 0 13 Framed-Compression 2378 0+ 0+ 0 0 0 0 14 Login-IP-Host 2379 0 0-1 0 0 0 0 15 Login-Service 2380 0 0-1 0 0 0 0 16 Login-TCP-Port 2381 0 0+ 0+ 0+ 0 0 18 Reply-Message 2382 0-1 0-1 0 0 0 0 19 Callback-Number 2383 0 0-1 0 0 0 0 20 Callback-Id 2384 0 0+ 0 0 0 0 22 Framed-Route 2385 0 0-1 0 0 0 0 23 Framed-IPX-Network 2386 0-1 0-1 0 0-1 0 0 24 State 2387 0 0+ 0 0 0 0 25 Class 2388 0 0-1 0 0-1 0-1 0-1 27 Session-Timeout 2389 0 0-1 0 0-1 0-1 0-1 28 Idle-Timeout 2390 0 0-1 0 0 0 0 29 Termination-Action 2391 0-1 0 0 0 0 0 30 Called-Station-Id 2392 0-1 0 0 0 0 0 31 Calling-Station-Id 2393 0-1 0 0 0 0 0 32 NAS-Identifier 2394 0+ 0+ 0+ 0+ 0+ 0+ 33 Proxy-State 2395 0-1 0-1 0 0 0 0 34 Login-LAT-Service 2396 0-1 0-1 0 0 0 0 35 Login-LAT-Node 2397 0-1 0-1 0 0 0 0 36 Login-LAT-Group 2398 0 0-1 0 0 0 0 37 Framed-AppleTalk-Link 2399 0 0+ 0 0 0 0 38 Framed-AppleTalk-Net. 2400 0 0-1 0 0 0 0 39 Framed-AppleTalk-Zone 2401 0-1 0 0 0 0 0 60 CHAP-Challenge 2402 0-1 0 0 0 0 0 61 NAS-Port-Type 2403 0-1 0-1 0 0 0 0 62 Port-Limit 2404 0-1 0-1 0 0 0 0 63 Login-LAT-Port 2405 0 0+ 0 0 0 0 280 Filter-Rule 2406 0 0 0 0 0+ 0+ 281 Framed-Password-Pol. 2407 Req Succ Fail Chal Disc-Req Disc-Rsp # Attribute 2409 [*1] An Access-Request MUST NOT contain both a User-Password and a 2410 CHAP-Password AVP. 2412 The following table defines the meaning of the above table 2413 entries. 2415 0 This attribute MUST NOT be present in packet. 2416 0+ Zero or more instances of this attribute MAY be present 2417 in packet. 2418 0-1 Zero or one instance of this attribute MAY be present 2419 in packet. 2420 1 Exactly one instance of this attribute MUST be present 2421 in 2422 packet. 2424 4.0 Protocol Definition 2426 This section will outline how the DIAMETER Authentication Extension 2427 can be used. 2429 4.1 Authorization Procedure 2431 This specification allows two different types of Authorization 2432 procedures. The first method is identical to the way RADIUS works 2433 today and requires the Access-Request to contain the UserName as well 2434 as either the Password or the CHAP-Password AVPs. 2436 The second method is used by NASes that send Access-Request whenever 2437 they receive an incoming call and want to get authorization from the 2438 DIAMETER Server to answer the call. In this case the Access-Request 2439 contains the NAS-IP-Address, the Calling-Station-Id and the Called- 2440 Station-Id AVPs. 2442 In this case the DIAMETER Server can lookup the combination of the 2443 Calling-Station-Id and the Called-Station-Id in order to ensure that 2444 the pair are authorized as per the local policy. 2446 4.2 Integration with Resource-Management 2448 Document [10] specifies the Resource-Token AVP that is used to carry 2449 information required for a DIAMETER server to rebuild its state 2450 information in the event of a crash or some other event that would 2451 cause the server to loose its state information. 2453 When creating the Resource-Token AVP, the following AVPs MUST be 2454 present, in addition to the AVPs listed in [10]; the UserName AVP, 2455 the NAS-IP- Address, the NAS-Port. Any additional AVP MAY be included 2456 if the AVP is a resource that is being managed (i.e. Framed-IP- 2457 Address in the case where the DIAMETER Server is allocating IP 2458 Addresses out of a centrally managed address pool). 2460 4.3 RADIUS Proxies 2462 In today's dial up networks the RADIUS protocol is used to 2463 authentication, authorize and perform accounting for dial-up users. 2464 However, it has become common practice to make use of RADIUS Servers 2465 known as proxies. 2467 The use of proxies has become widespread especially with the 2468 popularity of Internet Roaming[4]. In this example a user has a 2469 single user account with a local service provider. When this user 2470 roams outside of the ISP's service area, it is possible for the user 2471 to connect to another service provider (see [4] for more detail). 2473 In this scenario, the new service provider (ISPB) provides internet 2474 access for the user through a NAS (NASB). ISPB owns an authentication 2475 server (RADB), which proxies the authentication request to the user's 2476 original provider's authentication server (RADA). 2478 (Access-Request) (Access-Request) 2479 +------+ -----> +------+ ------> +------+ 2480 | | | | | | 2481 | NASB +--------------------+ RADB +--------------------+ RADA | 2482 | | | | | | 2483 +------+ <----- +------+ <------ +------+ 2484 (Access-Accept) (Access-Accept) 2486 The example shown above NASB generates an authentication request on 2487 behalf of the dial-in user to the RADB Authentication server. In this 2488 case, the user's identity would include a domain identifier [3] that 2489 would enable RADB to identify the authentication server (i.e. 2490 user@ISPA.com). 2492 The RADB server then forwards the request to RADA which authenticates 2493 the user based on information found within the request. If 2494 successfully authenticated the RADA server returns a successful 2495 response along with authorization information. If the user 2496 authentication fails RADA replies with a failed response. 2498 In the past this model has caused much concern over it's security 2499 implication. The model is much worse in the when there exists an 2500 intermediate provider between ISPB and ISPA (say ISPC). The following 2501 diagram depicts such an example where RADB must forward any requests 2502 for RADA through RADC. 2504 (Accounting-Request) (Accounting-Request) 2505 +------+ -----> +------+ ------> +------+ 2506 | | | | | | 2507 | RADB +--------------------+ RADC +--------------------+ RADA | 2508 | | | | | | 2509 +------+ <----- +------+ <------ +------+ 2510 (Accounting-Response) (Accounting-Response) 2512 The problem with the above scenario is that complete trust is placed 2513 in RADC (and hence ISPC) since it is very simple to modify any 2514 attributes found within the request or the response. The example 2515 shows an accounting request sent from RADB to RADA through RADC. The 2516 following is a list of a few attacks which can be generated by a 2517 malicious proxy: 2519 - Generating Accounting Records by replaying old 2520 authentication/accounting records. In this example it is very 2521 simple for RADC to simple retain old packets and replay then at a 2522 later date. This will cause RADA to "pay" for services which were 2523 never rendered. 2525 - Modify Attributes within the request or response. In this case 2526 RADC can modify attributes, such as the length of the call, that 2527 would fool RADA into believing the call was longer than in 2528 reality. 2530 - Stealing PAP Passwords is another problem with today's proxies. 2531 In the current model PAP passwords are encrypted using a shared 2532 secret which is shared between each hop in the proxy chain. In 2533 this case each hop has the opportunity to decrypt, and possibly 2534 save for future use, the user's password. 2536 Given the problems identified above with the current proxy model it 2537 is necessary to create a mechanism which allows for non-repudiation, 2538 end-to-end data integrity as well as end-to-end encryption. Given the 2539 current encryption technology this can only be achieved with the use 2540 of asymetric encryption and digital signatures. 2542 4.4 DIAMETER Proxies 2544 The DIAMETER protocol also makes use of proxies in order to keep the 2545 existing arrangements while migrating from RADIUS to DIAMETER. 2546 However since DIAMETER makes use of asymetric encryption and digital 2547 signatures it solves many of the problems shown above. 2549 (Access-Request) (Access-Request) 2550 +------+ -----> +------+ ------> +------+ 2551 | | | | | | 2552 | NASB +--------------------+ DIA2 +--------------------+ DIA1 | 2553 | | | | | | 2554 +------+ <----- +------+ <------ +------+ 2555 (Access-Response) (Access-Response) 2557 In this example NASB generates an Access-Request that is forwarded to 2558 DIA2. The Access-Request contains a digital signature AVP which 2559 "protects" all mandatory (or non-editable) AVPs within the request. 2560 All AVPs which may be modified, or removed appear after the digital 2561 signature AVP. Once DIA2 receives the request, it MAY authenticate 2562 the request to ensure that it was originated by NASB (verifying the 2563 signature is not necessary if the link between NASB and DIA2 is 2564 secured using IPSEC). 2566 The DIA2 Server may then add new attributes to the request. All 2567 mandatory AVPs MUST be present prior to the non mandatory AVPs and 2568 MUST be preceeded by a Digital Signature AVP (using DIA2's private 2569 key). Note that all non-mandatory AVPs added to the packet by NASB 2570 must appear after DIA2's digital signature AVP. The message is then 2571 forwarded towards the DIA1 server. 2573 Since all packets between NASB and DIA1 must flow through DIA2, it is 2574 not possible to use IPSEC between both hosts. Therefore DIA1 MUST 2575 validate NASB's digital signature AVP. However it is not necessary to 2576 validate DIA2's digital signature if the link between DIA2 and DIA1 2577 is secured using IPSEC. 2579 This mechanism now provides a method for DIA1 to prove that NASB was 2580 the initiator of the request (note that DIAMETER also includes a 2581 timestap to prevent replay attacks). It also provides a method of 2582 ensuring that DIA2 cannot modify any "non-editable" attributes (such 2583 as length of call, etc). 2585 In addition, this same mechanism can be used for end-to-end 2586 encryption of AVPs. In the case where NASB needs to encrypt an AVP it 2587 is done using asymetric encryption using DIA1's public key. This 2588 ensures that only DIA1 can decrypt the AVP. 2590 An attack has been identified in this proposal which allows a 2591 malicous man in the middle attack as shown in the following diagram. 2593 (Access-Request) (Access-Request) (Access-Request) 2594 +------+ -----> +------+ -----> +------+ -----> +------+ 2595 | | | | | | | | 2596 | NASB +----------+ DIA2 +----------+ DIA3 +----------+ DIA1 | 2597 | | | | | | | | 2598 +------+ <----- +------+ <----- +------+ <----- +------+ 2599 (Access-Response) (Access-Response) (Access-Response) 2601 In this example, DIA3 traps packets generated from DIA2 towards DIA1, 2602 removes the AVPs added by DIA2 and inserts its own AVPs (posibly by 2603 trying to convince DIA1 to pay DIA3 for the services). This attack 2604 can be prevented by supporting a new Next-Hop AVP. In this case when 2605 NASB prepares a request it inserts a non-editable Next-Hop AVP which 2606 contains DIA2's identitity. DIA2 also adds a Next-Hop AVP with DIA1 2607 as the next hop. 2609 This mechanism ensures that a man in the middle cannot alter the 2610 packet by overriding the previous hop's additions and signature. DIA1 2611 could easily validate the packet's path with the use of the Next-Hop 2612 AVPs. 2614 4.5 Domain Discovery 2616 The Domain Discovery message set is very useful in determining the 2617 Home authentication server, the password policies for the domain, as 2618 a mechanism to retrieve a certificate (or a pointer to a 2619 certificate). 2621 The following example shows a case where DIA1 needs to communicate 2622 with DIA3. In this example it is necessary to use DIA2 as a proxy in 2623 order for both ISPs to communicate. Although this MAY be desireable 2624 in some business models, there are cases where it is beneficial to 2625 remove the proxy altogether and allow both DIA3 and DIA1 to 2626 communicate in a secure fashion. 2628 (DD-Request) (DD-Request) 2629 +------+ -----> +------+ ------> +------+ 2630 | | | | | | 2631 | DIA1 +--------------------+ DIA2 +--------------------+ DIA3 | 2632 | | | | | | 2633 +------+ <----- +------+ <------ +------+ 2634 (DD-Response) (DD-Response) 2636 The way the Domain Discovery works is that prior to sending out an 2637 authentication request DIA1 would issue a Domain Discovery message 2638 towards DIA2. This message is protected with the digital signature as 2639 well as the Next-Hop AVP. DIA2 would then forward the request to DIA3 2640 including the Next-Hop and the digital signature AVP. 2642 When DIA3 receives the request, it MUST save the certificate (or the 2643 pointer to the certificate) and respond back including the local 2644 password policy, DIA3's certificate, it's contact information (i.e. 2645 IP address) and protect the response with the digital signature. 2647 Note that in all cases the TimeStamp AVP is also present to ensure no 2648 reply packets are accepted. 2650 When DIA2 receives the packet, it must add the Next-Hop AVP as well 2651 as the digital signature AVP. When DIA1 receives the packet it then 2652 knows a direct route to communicate with DIA3 since the contact 2653 information is present in the response. The fact that both DIA1 and 2654 DIA3 can now communicate directly allows both peers to use IPSEC to 2655 protect the message exchange (note that it MAY be desirable to also 2656 use the digital signature in order to keep the information in the 2657 DIAMETER logs). 2659 (Access-Request) 2660 +------+ -----> +------+ 2661 | | | | 2662 | DIA1 +--------------------+ DIA3 | 2663 | | | | 2664 +------+ <----- +------+ 2665 (Access-Response) 2667 In addition, the password policy is also present which can indicate 2668 whether DIA3 is willing to accept CHAP, PAP or EAP authentication. 2670 Note that the Domain-Request/Response MAY include the Supported- 2671 Extension AVPs [2]. 2673 5.0 References 2675 [1] Rigney, et alia, "RADIUS", RFC-2138, Livingston, April 1997 2677 [2] Calhoun, Rubens, "DIAMETER Base Protocol", Internet-Draft, 2678 draft-calhoun-diameter-03.txt, May 1998. 2680 [3] Aboba, Beadles, "Network Address Identifier", Internet- 2681 Draft, draft-ietf-roamops-nai-10.txt, February 1998. 2683 [4] Aboba, Zorn, "Dialup Roaming Requirements", Internet-Draft, 2684 July 1997. 2686 [5] Calhoun, Rubens, Aboba, "DIAMETER Extensible Authentication 2687 Protocol Extensions", Internet-Draft, draft-calhoun- 2688 diameter-eap-01.txt, March 1998. 2690 [6] Calhoun, Haag, Zorn, "EAP Authentication for SOCKS 2691 Version 5", draft-ietf-aft-socks-eap-00.txt, March 1998. 2693 [7] Jacobson, "Compressing TCP/IP headers for low-speed serial 2694 links", RFC 1144, February 1990. 2696 [8] ISO 8859. International Standard -- Information Processing -- 2697 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin 2698 Alphabet No. 1, ISO 8859-1:1987. 2699 2701 [9] Sklower, Lloyd, McGregor, Carr, "The PPP Multilink Protocol 2702 (MP)", RFC 1717, November 1994. 2704 [10] Calhoun, Greene, "DIAMETER Resource Management Extension", 2705 Internet-Draft, draft-calhoun-diameter-res-mgmt-01.txt, 2706 May 1998. 2708 [11] Calhoun, Zorn, Pan, "DIAMETER Framework", Internet- 2709 Draft, draft-calhoun-diameter-framework-00.txt, May 1998 2711 6.0 Acknowledgements 2713 The Author wishes to thank Carl Rigney since much of the text in the 2714 document was shamefully copied from [1] as well as the following 2715 people for their help in the development of this protocol: 2717 Nancy Greene, Ryan Moats 2719 7.0 Authors' Addresses 2721 Questions about this memo can be directed to: 2723 Pat R. Calhoun 2724 Technology Development 2725 Sun Microsystems, Inc. 2726 15 Network Circle 2727 Menlo Park, California, 94025 2728 USA 2729 Phone: 1-650-786-7733 2730 Fax: 1-650-786-6445 2731 E-mail: pcalhoun@eng.sun.com 2733 William Bulley 2734 Merit Network, Inc. 2735 4251 Plymouth Road, Suite C 2736 Ann Arbor, Michigan, 48105-2785 2737 USA 2739 Phone: 1-734-764-9993 2740 Fax: 1-734-647-3185 2741 E-mail: web@merit.edu