idnits 2.17.1 draft-calhoun-diameter-authent-02.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-25) 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. 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 401 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 563 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 123: '... MUST This word, or the adject...' RFC 2119 keyword, line 127: '... MUST NOT This phrase means that t...' RFC 2119 keyword, line 130: '... SHOULD This word, or the adject...' RFC 2119 keyword, line 136: '... MAY This word, or the adject...' RFC 2119 keyword, line 138: '...hich does not include this option MUST...' (185 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '... This docum...' == Line 14 has weird spacing: '...cuments of t...' == Line 15 has weird spacing: '... groups may ...' == Line 20 has weird spacing: '...iate to use ...' == Line 21 has weird spacing: '... as referen...' == (396 more instances...) -- 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.) -- The document date (March 1998) is 9538 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2138 (ref. '1') (Obsoleted by RFC 2865) == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-00 -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- 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' == Outdated reference: A later version (-12) exists of draft-ietf-roamops-nai-10 Summary: 13 errors (**), 0 flaws (~~), 10 warnings (==), 7 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-02.txt 5 Date: March 1998 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 months. 19 Internet-Drafts may be updated, replaced, or obsoleted by other 20 documents at any time. It is not appropriate to use Internet-Drafts 21 as reference material or to cite them other than as a ``working 22 draft'' or ``work in progress.'' 24 To learn the current status of any Internet-Draft, please check the 25 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 26 Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or 27 munnari.oz.au. 29 Abstract 31 DIAMETER is a Policy and AAA protocol which can be used for a variety 32 of services. This document defines DIAMETER messages that are used for 33 the authentication, authorization and accounting of users. 35 A considerable amount of effort was put into the design of this 36 protocol to ensure that an implementation could support both DIAMETER 37 and RADIUS concurrently. 39 Table of Contents 41 1.0 Introduction 42 1.1 Specification of Requirements 43 2.0 Command Codes 44 2.1 Domain-Discovery-Request 45 2.2 Domain-Discovery-Response 46 2.3 Authentication-Request 47 2.4 Authentication-Success 48 2.5 Authentication-Failure 49 2.6 Authentication-Challenge 50 3.0 DIAMETER AVPs 51 3.1 User-Name 52 3.2 User-Password 53 3.3 CHAP-Password 54 3.4 NAS-Port 55 3.5 Service-Type 56 3.6 Framed-Protocol 57 3.7 Framed-IP-Address 58 3.8 Framed-IP-Netmask 59 3.9 Framed-Routing 60 3.10 Filter-Id 61 3.11 Framed-MTU 62 3.12 Framed-Compression 63 3.13 Login-IP-Host 64 3.14 Login-Service 65 3.15 Login-TCP-Port 66 3.16 Reply-Message 67 3.17 Callback-Number 68 3.18 Callback-Id 69 3.19 Framed-Route 70 3.20 Framed-IPX-Network 71 3.21 State 72 3.22 Class 73 3.23 Vendor-Specific 74 3.24 Session-Timeout 75 3.25 Idle-Timeout 76 3.26 Termination-Action 77 3.27 Called-Station-Id 78 3.28 Calling-Station-Id 79 3.29 Proxy-State 80 3.30 Login-LAT-Service 81 3.31 Login-LAT-Node 82 3.32 Login-LAT-Group 83 3.33 Framed-AppleTalk-Link 84 3.34 Framed-AppleTalk-Network 85 3.35 Framed-AppleTalk-Zone 86 3.36 CHAP-Challenge 87 3.37 NAS-Port-Type 88 3.38 Port-Limit 89 3.39 Login-LAT-Port 90 3.40 Framed-Password-Policy 91 3.41. Table of Attributes 92 5.0 Protocol Definition 93 5.1 RADIUS Proxies 94 5.2 DIAMETER Proxies 95 5.2 Domain Discovery 96 6.0 Acknowledgements 97 7.0 References 98 8.0 Authors' Addresses 100 1.0 Introduction 102 This document describes the DIAMETER User Authentication Extensions 103 that can be used for a variety of services including Dial-up users via 104 NAS', Web User Authentication, Firewall User Authentication[5][6]. 106 This document describes Authentication/Authorization messages as well 107 as a set of messages which allow DIAMETER hosts to bypass proxies. 109 Since Most of the AVPs found in this document was copied from the 110 RADIUS protocol[1], it is possible to have both RADIUS and DIAMETER 111 servers read the same dictionary and users files. The backward 112 compatibility that DIAMETER offers is intended to facilitate 113 deployment. 115 The Extension number for this draft is 1. This value is used in the 116 Supported-Extension AVP as defined in [2]. 118 1.1 Specification of Requirements 120 In this document, several words are used to signify the requirements 121 of the specification. These words are often capitalized. 123 MUST This word, or the adjective "required", means that the 124 definition is an absolute requirement of the 125 specification. 127 MUST NOT This phrase means that the definition is an absolute 128 prohibition of the specification. 130 SHOULD This word, or the adjective "recommended", means that 131 there may exist valid reasons in particular circumstances 132 to ignore this item, but the full implications must be 133 understood and carefully weighed before choosing a 134 different course. 136 MAY This word, or the adjective "optional", means that this 137 item is one of an allowed set of alternatives. An 138 implementation which does not include this option MUST 139 be prepared to interoperate with another implementation 140 which does include the option. 142 2.0 Command Codes 144 This document defines the following DIAMETER Commands. All DIAMETER 145 implementations supporting this extension MUST support all of the 146 following commands: 148 Command Name Command Code 149 ----------------------------------- 150 Domain-Discovery-Request 261 151 Domain-Discovery-Response 262 152 Authentication-Request 263 153 Authentication-Success 264 154 Authentication-Failure 265 155 Authentication-Challenge 266 157 2.1 Domain-Discovery-Request 159 Description 161 The Domain-Discovery-Request message is used by a DIAMETER device 162 wishing to get contact information about a domain's home 163 authentication server as well as to receive password policy 164 information. This message MUST contain the User-Name attribute in 165 order to pass along the user's domain information. 167 The X509-Certificate or the X509-Certificate-URL [2] MUST be 168 present in this message in order to inform the home authentication 169 server of the issuing host's certificate. 171 A summary of the Domain-Discovery-Request packet format is shown 172 below. The fields are transmitted from left to right. 174 0 1 2 3 175 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 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | AVP Code | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | AVP Length | AVP Flags | Reserved | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Command Type | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Code 185 256 DIAMETER Command 187 AVP Length 189 The length of this attribute MUST be 10. 191 AVP Flagss 193 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 195 Command Type 197 The Command Type field MUST be set to 261 (Domain-Discovery- 198 Request). 200 2.2 Domain-Discovery-Response 202 Description 204 The Domain-Discovery-Response message is sent in response to the 205 Domain-Discovery-Request message by the domain's Home 206 authentication server. The message MUST contain either the Host- 207 Name or Host-IP-Address and either the X509-Certificate or the 208 X509-Certificate-URL attribute and SHOULD contain at least one 209 Framed-Password-Policy AVP. 211 The absence of any Framed-Password-Policy AVPs means that the 212 issuer will only accept CHAP and PAP. 214 A summary of the Domain-Discovery-Response packet format is shown 215 below. The fields are transmitted from left to right. 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | AVP Code | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | AVP Length | AVP Flags | Reserved | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Command Type | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Code 229 256 DIAMETER Command 231 AVP Length 233 The length of this attribute MUST be 10. 235 AVP Flagss 237 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 239 Command Type 241 The Command Type field MUST be set to 262 (Domain-Discovery- 242 Response). 244 2.3 Authentication-Request 246 Description 248 The Authentication-Request message is used in order to request 249 authentication and authorization for a given user. 251 If Authentication is requested the User-Name attribute MUST be 252 present. If only Authorization is required it is possible to 253 authorize based on DNIS and ANI instead. However, it is not 254 possible to authenticate using a User-Name AVP and later requesting 255 authorization based on DNIS using the same Session-Id (although the 256 inverse is legal). 258 Note that the flag field MAY be used in this command in order to 259 indicate that either Authentication-Only or Authorization-Only is 260 required for the request. If the Authentication-Only bit is set the 261 response MUST NOT include any authorization information. Both the 262 Authenticate and Authorize bits MUST NOT be set at the same time. 263 To ensure that a command is both authenticated and authorized, 264 neither flag is set. 266 A summary of the Authentication-Request packet format is shown 267 below. The fields are transmitted from left to right. 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | AVP Code | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | AVP Length | AVP Flags | Reserved | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Command Type | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Code 281 256 DIAMETER Command 283 AVP Length 284 The length of this attribute MUST be 7. 286 AVP Flagss 288 The AVP Flags field MUST have bit 1 (Mandatory Support) set. In 289 addition, the following bits may be used (note these bits are 290 mutually exclusive): 292 Authenticate-Only 32 293 The Authentication-Only bit is set to indicate that only 294 authentication of the user is requested and that no 295 authorization information should be returned in the response. 297 Authorize-Only 64 298 The Authorization-Only bit is set to indicate that only 299 authorization of the user is requested and that no 300 authentication is required. 302 Command Type 304 The Command Type field MUST be set to 263 (Authentication-Request). 306 2.4 Authentication-Success 308 Description 310 The Authentication-Success message is used in order to indicate 311 that Authentication (or authorization) was successful. If 312 authorization was requested a list of AVPs with the authorization 313 information MUST be attached to the message (see section 4.40). 315 Note that the flag field MUST be set to the same value that was 316 found in the Authentication-Request message. 318 A summary of the Authentication-Success packet format is shown 319 below. The fields are transmitted from left to right. 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | AVP Code | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | AVP Length | AVP Flags | Reserved | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Command Type | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Code 332 256 DIAMETER Command 334 AVP Length 336 The length of this attribute MUST be 10. 338 AVP Flagss 340 The AVP Flags field MUST have bit 1 (Mandatory Support) set. In 341 addition, the following bits may be used (note these bits are 342 mutually exclusive): 344 Authenticate-Only 32 345 The Authentication-Only bit is set to indicate that only 346 authentication of the user is requested and that no 347 authorization information should be returned in the response. 349 Authorize-Only 64 350 The Authorization-Only bit is set to indicate that only 351 authorization of the user is requested and that no 352 authentication is required. 354 Command Type 356 The Command Type field MUST be set to 264 (Authentication-Success). 358 2.5 Authentication-Failure 360 Description 362 The Authentication-Failure message is used in order to indicate 363 that Authentication (or authorization) was unsuccessful. The list 364 of AVPs that may be attached to this message can be found in 365 section 4.40. 367 Note that the flag field MUST be set to the same value that was 368 found in the Authentication-Request message. 370 A summary of the Authentication-Failure packet format is shown 371 below. The fields are transmitted from left to right. 373 0 1 2 3 374 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 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | AVP Code | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | AVP Length | AVP Flags | Reserved | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Command Type | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 Code 385 256 DIAMETER Command 387 AVP Length 389 The length of this attribute MUST be 10. 391 AVP Flagss 393 The AVP Flags field MUST have bit 1 (Mandatory Support) set. In 394 addition, the following bits may be used (note these bits are 395 mutually exclusive): 397 Authenticate-Only 32 398 The Authentication-Only bit is set to indicate that only 399 authentication of the user is requested and that no 400 authorization information should be returned in the response. 402 Authorize-Only 64 403 The Authorization-Only bit is set to indicate that only 404 authorization of the user is requested and that no 405 authentication is required. 407 Command Type 409 The Command Type field MUST be set to 265 (Authentication-Failure). 411 2.6 Authentication-Challenge 413 Description 415 If the DIAMETER server desires to send the user a challenge 416 requiring a response, then the DIAMETER server MUST respond to the 417 Authentication-Request by transmitting a packet with the Code field 418 set to 266 (Authentication-Challenge). 420 The message MAY have one or more Reply-Message AVP, and MAY have a 421 single State AVP, or none. No other AVPs are permitted in an 422 Authentication-Challenge other than the Integrity-Check-Vector or 423 Digital-Signature AVP as defined in [2]. 425 On receipt of an Authentication-Challenge, the Identifier field is 426 matched with a pending Authentication-Request. Invalid packets are 427 silently discarded. 429 The receipt of a valid Authentication-Challenge indicates that a 430 new Authentication-Request SHOULD be sent. The NAS MAY display the 431 text message, if any, to the user, and then prompt the user for a 432 response. It then sends its original Authentication-Request with a 433 new request ID, with the User-Password AVP replaced by the user's 434 response (encrypted), and including the State AVP from the 435 Authentication-Challenge, if any. Only 0 or 1 instances of the 436 State Attribute can be present in an Authentication-Request. 438 A NAS which supports PAP MAY forward the Reply-Message to the 439 dialin client and accept a PAP response which it can use as though 440 the user had entered the response. If the NAS cannot do so, it 441 should treat the Authentication-Challenge as though it had received 442 an Authentication-Failure instead. 444 It is preferable to use EAP [5] instead of the Authentication- 445 Challenge, yet it has been maintained for backward compatibility. 447 The Authentication-Failure message is used in order to indicate 448 that Authentication (or authorization) was unsuccessful. The list 449 of AVPs that may be attached to this message can be found in 450 section 4.40. 452 Note that the flag field MUST be set to the same value that was 453 found in the Authentication-Request message. 455 A summary of the Authentication-Failure packet format is shown 456 below. The fields are transmitted from left to right. 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | AVP Code | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | AVP Length | AVP Flags | Reserved | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Command Type | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 Code 470 256 DIAMETER Command 472 AVP Length 474 The length of this attribute MUST be 10. 476 AVP Flagss 478 The AVP Flags field MUST have bit 1 (Mandatory Support) set. In 479 addition, following bits may be used (note these bits are mutually 480 exclusive): 482 Authenticate-Only 32 483 The Authentication-Only bit is set to indicate that only 484 authentication of the user is requested and that no 485 authorization information should be returned in the response. 487 Authorize-Only 64 488 The Authorization-Only bit is set to indicate that only 489 authorization of the user is requested and that no 490 authentication is required. 492 Command Type 494 The Command Type field MUST be set to 266 (Authentication-Failure). 496 3.0 DIAMETER AVPs 498 This section will define the mandatory AVPs which MUST be supported by 499 all DIAMETER implementations supporting this extension. The following 500 AVPs are defined in this document: 502 Attribute Name Attribute Code 503 ----------------------------------- 504 User-Name 1 505 User-Password 2 506 CHAP-Password 3 507 NAS-IP-Address 4 508 NAS-Port 5 509 Service-Type 6 510 Framed-Protocol 7 511 Framed-IP-Address 8 512 Framed-IP-Netmask 9 513 Framed-Routing 10 514 Filter-Id 11 515 Framed-MTU 12 516 Framed-Compression 13 517 Login-IP-Host 14 518 Login-Service 15 519 Login-TCP-Port 16 520 Reply-Message 18 521 Callback-Number 19 522 Callback-Id 20 523 Framed-Route 22 524 Framed-IPX-Network 23 525 State 24 526 Class 25 527 Vendor-Specific 26 528 Session-Timeout 27 529 Idle-Timeout 28 530 Termination-Action 29 531 Called-Station-Id 30 532 Calling-Station-Id 31 533 NAS-Identifier 32 534 Proxy-State 33 535 Login-LAT-Service 34 536 Login-LAT-Node 35 537 Login-LAT-Group 36 538 Framed-AppleTalk-Link 37 539 Framed-AppleTalk-Network 38 540 Framed-AppleTalk-Zone 39 541 CHAP-Challenge 60 542 NAS-Port-Type 61 543 Port-Limit 62 544 Login-LAT-Port 63 545 Framed-Password-Policy 268 547 3.1. User-Name 549 Description 551 This Attribute indicates the name of the user to be authenticated. 552 It is normally used in Authentication-Request packets, but MAY be 553 present in the Authentication-Success message. 555 A summary of the User-Name Attribute format is shown below. The 556 fields are transmitted from left to right. 558 0 1 2 3 559 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 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | AVP Code | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | AVP Length | AVP Flags | Reserved | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | String ... 566 +-+-+-+-+-+-+-+-+ 568 Type 570 1 for User-Name. 572 AVP Length 574 The length of this attribute MUST be at least 9. 576 AVP Flagss 577 The AVP Flags field MUST have bit 1 (Mandatory Support) set. The 578 SS-Encrypted-Data bit SHOULD be set if a shared secret exists. The 579 PK-Encrypted-data bit SHOULD NOT be set since intermediate DIAMETER 580 servers will require this information in order to determine the 581 home DIAMETER server. 583 String 585 The String field is one or more octets. All DIAMETER systems SHOULD 586 support User-Name lengths of at least 63 octets. The format of the 587 User-Name SHOULD follow the format defined in [7]. 589 3.2. User-Password 591 Description 593 This Attribute indicates the password of the user to be 594 authenticated, or the user's input following an Authentication- 595 Challenge. It is only used in Authentication-Request packets. 597 This AVP MUST be encrypted using one of the methods described in 598 [2]. The use of this AVP with shared secret encryption is strongly 599 discouraged by the author due to the security implications in a 600 proxy environment, yet the support of this attribute has been 601 retained for RADIUS backward compability. 603 A summary of the User-Password Attribute format is shown below. The 604 fields are transmitted from left to right. 606 0 1 2 3 607 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 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | AVP Code | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | AVP Length | AVP Flags | Reserved | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Data ... 614 +-+-+-+-+-+-+-+-+ 616 Type 618 2 for User-Password. 620 AVP Length 622 The length of this attribute MUST be at least 24 and no larger than 623 136. 625 AVP Flagss 626 The AVP Flags field MUST have bit 1 (Mandatory Support) set. One of 627 the AVP Encryption bits MUST be set. 629 Data 631 The Data field is between 16 and 128 octets long, inclusive. 633 3.3. CHAP-Password 635 Description 637 This Attribute indicates the response value provided by a PPP 638 Challenge-Handshake Authentication Protocol (CHAP) user in response 639 to the challenge. It is only used in Authenticate-Request packets. 641 If the CHAP-Password Attribute is found in a message, the CHAP- 642 Challenge Attribute (60) MUST be present as well. 644 A summary of the CHAP-Password Attribute format is shown below. The 645 fields are transmitted from left to right. 647 0 1 2 3 648 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 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | AVP Code | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | AVP Length | AVP Flags | Reserved | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | CHAP Ident | Data ... 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 Type 659 3 for CHAP-Password. 661 AVP Length 663 The length of this attribute MUST be 25. 665 AVP Flagss 667 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 669 CHAP Ident 671 This field is one octet, and contains the CHAP Identifier from the 672 user's CHAP Response. 674 Data 675 The Data field is 16 octets, and contains the CHAP Response from 676 the user. 678 3.4. NAS-Port 680 Description 682 This Attribute indicates the physical port number of the NAS which 683 is authenticating the user. It is only used in Authetication- 684 Request messages. Note that this is using "port" in its sense of a 685 physical connection on the NAS, not in the sense of a TCP or UDP 686 port number. Either NAS-Port or NAS-Port-Type (61) or both SHOULD 687 be present in an Authentication-Request packet, if the NAS 688 differentiates among its ports. 690 A summary of the NAS-Port Attribute format is shown below. The 691 fields are transmitted from left to right. 693 0 1 2 3 694 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 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | AVP Code | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | AVP Length | AVP Flags | Reserved | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Integer32 | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 Type 705 5 for NAS-Port. 707 AVP Length 709 The length of this attribute MUST be 12. 711 AVP Flagss 713 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 715 Integer32 717 The Integer32 field is four octets. 719 3.5. Service-Type 721 Description 722 This Attribute indicates the type of service the user has 723 requested, or the type of service to be provided. It MAY be used in 724 both Authentication-Request and Authentication-Success messages. A 725 NAS is not required to implement all of these service types, and 726 MUST treat unknown or unsupported Service-Types as though an 727 Authentication-Failure had been received instead. 729 A summary of the Service-Type Attribute format is shown below. The 730 fields are transmitted from left to right. 732 0 1 2 3 733 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 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | AVP Code | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | AVP Length | AVP Flags | Reserved | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Integer32 | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 Type 744 6 for Service-Type. 746 AVP Flagss 748 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 750 AVP Length 752 The length of this attribute MUST be 12. 754 Integer32 756 The Integer32 field is four octets. 758 1 Login 759 2 Framed 760 3 Callback Login 761 4 Callback Framed 762 5 Outbound 763 6 Administrative 764 7 NAS Prompt 765 8 Authenticate Only 766 9 Callback NAS Prompt 768 The service types are defined as follows when used in an 769 Authetication-Success. When used in an Authentication-Request, they 770 should be considered to be a hint to the DIAMETER server that the NAS 771 has reason to believe the user would prefer the kind of service 772 indicated, but the server is not required to honor the hint. 774 Login The user should be connected to a host. 776 Framed A Framed Protocol should be started for the 777 User, such as PPP or SLIP. 779 Callback Login The user should be disconnected and called 780 back, then connected to a host. 782 Callback Framed The user should be disconnected and called 783 back, then a Framed Protocol should be started 784 for the User, such as PPP or SLIP. 786 Outbound The user should be granted access to outgoing 787 devices. 789 Administrative The user should be granted access to the 790 administrative interface to the NAS from which 791 privileged commands can be executed. 793 NAS Prompt The user should be provided a command prompt 794 on the NAS from which non-privileged commands 795 can be executed. 797 Authenticate Only Only Authentication is requested, and no 798 authorization information needs to be returned 799 in the Authentication-Success (typically used by 800 proxy servers rather than the NAS itself). This 801 SHOULD NOT be used in DIAMETER, yet it is 802 maintained for backward compatibility. 804 Callback NAS Prompt The user should be disconnected and called 805 back, then provided a command prompt on the 806 NAS from which non-privileged commands can be 807 executed. 809 3.6. Framed-Protocol 811 Description 813 This Attribute indicates the framing to be used for framed access. 814 It MAY be used in both Authentication-Request and Authentication- 815 Success messages. 817 A summary of the Framed-Protocol Attribute format is shown below. 818 The fields are transmitted from left to right. 820 0 1 2 3 821 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 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | AVP Code | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | AVP Length | AVP Flags | Reserved | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | Integer32 | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 Type 832 7 for Framed-Protocol. 834 AVP Length 836 The length of this attribute MUST be 12. 838 AVP Flagss 840 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 842 Integer32 844 The Integer32 field is four octets. 846 1 PPP 847 2 SLIP 848 3 AppleTalk Remote Access Protocol (ARAP) 849 4 Gandalf proprietary SingleLink/MultiLink protocol 850 5 Xylogics proprietary IPX/SLIP 852 3.7. Framed-IP-Address 854 Description 856 This Attribute indicates the address to be configured for the user. 857 It MAY be used in Authentication-Request messages as a hint by the 858 NAS to the server that it would prefer that address, but the server 859 is not required to honor the hint. 861 A summary of the Framed-IP-Address Attribute format is shown below. 862 The fields are transmitted from left to right. 864 0 1 2 3 865 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 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | AVP Code | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | AVP Length | AVP Flags | Reserved | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Address | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 Type 876 8 for Framed-IP-Address. 878 AVP Length 880 The length of this attribute MUST be 12. 882 AVP Flagss 884 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 886 Address 888 The Address field is four octets. The value 0xFFFFFFFF indicates 889 that the NAS should allow the user to select an address (e.g. 890 Negotiated). The value 0xFFFFFFFE indicates that the NAS should 891 select an address for the user (e.g. Assigned from a pool of 892 addresses kept by the NAS). Other valid values indicate that the 893 NAS should use that value as the user's IP address. 895 3.8. Framed-IP-Netmask 897 Description 899 This Attribute indicates the IP netmask to be configured for the 900 user when the user is a router to a network. It MUST be used in 901 Authentication-Success messages if the Framed-IP-Address AVP was 902 returned with a value other than 0xFFFFFFFF. It MAY be used in an 903 Authentication-Request message as a hint by the NAS to the server 904 that it would prefer that netmask, but the server is not required 905 to honor the hint. 907 A summary of the Framed-IP-Netmask Attribute format is shown below. 908 The fields are transmitted from left to right. 910 0 1 2 3 911 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 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | AVP Code | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | AVP Length | AVP Flags | Reserved | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | Address | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 Type 922 9 for Framed-IP-Netmask. 924 AVP Length 926 The length of this attribute MUST be 12. 928 AVP Flagss 930 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 932 Address 934 The Address field is four octets specifying the IP netmask of the 935 user. 937 3.9. Framed-Routing 939 Description 941 This Attribute indicates the routing method for the user, when the 942 user is a router to a network. It is only used in Authentication- 943 Success messages. 945 A summary of the Framed-Routing Attribute format is shown below. 946 The fields are transmitted from left to right. 948 0 1 2 3 949 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 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | AVP Code | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | AVP Length | AVP Flags | Reserved | 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 | Integer32 | 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 Type 960 10 for Framed-Routing. 962 AVP Length 964 The length of this attribute MUST be 12. 966 AVP Flagss 968 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 970 Integer32 972 The Integer32 field is four octets. 974 0 None 975 1 Send routing packets 976 2 Listen for routing packets 977 3 Send and Listen 979 3.10. Filter-Id 981 Description 983 This Attribute indicates the name of the filter list for this user. 984 Zero or more Filter-Id attributes MAY be sent in an Authentication- 985 Success message. 987 Identifying a filter list by name allows the filter to be used on 988 different NASes without regard to filter-list implementation 989 details. However, this AVP is not roaming friendly since filter 990 naming differ from one service provider to another. 992 It is strongly encouraged to support the Filter-Rule AVP instead. 994 A summary of the Filter-Id Attribute format is shown below. The 995 fields are transmitted from left to right. 997 0 1 2 3 998 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 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | AVP Code | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | AVP Length | AVP Flags | Reserved | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 | String ... 1005 +-+-+-+-+-+-+-+-+ 1007 Type 1009 11 for Filter-Id. 1011 AVP Length 1013 The length of this attribute MUST be at least 9. 1015 AVP Flagss 1017 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 1019 String 1021 The String field is one or more octets, and its contents are 1022 implementation dependent. It is intended to be human readable and 1023 MUST NOT affect operation of the protocol. It is recommended that 1024 the message contain displayable ASCII characters from the range 32 1025 through 126 decimal. 1027 3.11. Framed-MTU 1029 Description 1031 This Attribute indicates the Maximum Transmission Unit to be 1032 configured for the user, when it is not negotiated by some other 1033 means (such as PPP). It is only used in Authentication-Success 1034 messages. 1036 A summary of the Framed-MTU Attribute format is shown below. The 1037 fields are transmitted from left to right. 1039 0 1 2 3 1040 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 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 | AVP Code | 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 | AVP Length | AVP Flags | Reserved | 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 | Integer32 | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 Type 1051 12 for Framed-MTU. 1053 AVP Length 1055 The length of this attribute MUST be 12. 1057 AVP Flagss 1059 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 1061 Integer32 1063 The Integer32 field is four octets. Despite the size of the field, 1064 values range from 64 to 65535. 1066 3.12. Framed-Compression 1067 Description 1069 This Attribute indicates a compression protocol to be used for the 1070 link. It MAY be used in Authentication-Success packets. It MAY be 1071 used in an Authentication-Request packet as a hint to the server 1072 that the NAS would prefer to use that compression, but the server 1073 is not required to honor the hint. 1075 More than one compression protocol Attribute MAY be sent. It is the 1076 responsibility of the NAS to apply the proper compression protocol 1077 to appropriate link traffic. 1079 A summary of the Framed-Compression Attribute format is shown 1080 below. The fields are transmitted from left to right. 1082 0 1 2 3 1083 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 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 | AVP Code | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 | AVP Length | AVP Flags | Reserved | 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 | Integer32 | 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 Type 1094 13 for Framed-Compression. 1096 AVP Length 1098 The length of this attribute MUST be 12. 1100 AVP Flagss 1102 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 1104 Integer32 1106 The Integer32 field is four octets. 1108 0 None 1109 1 VJ TCP/IP header compression [5] 1110 2 IPX header compression 1112 3.13. Login-IP-Host 1114 Description 1115 This Attribute indicates the system with which to connect the user, 1116 when the Login-Service Attribute is included. It MAY be used in 1117 Authentication-Success messages. It MAY be used in an 1118 Authentication-Request message as a hint to the server that the NAS 1119 would prefer to use that host, but the server is not required to 1120 honor the hint. 1122 A summary of the Login-IP-Host Attribute format is shown below. The 1123 fields are transmitted from left to right. 1125 0 1 2 3 1126 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 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 | AVP Code | 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | AVP Length | AVP Flags | Reserved | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 | Address | 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 Type 1137 14 for Login-IP-Host. 1139 AVP Length 1141 The length of this attribute MUST be 12. 1143 AVP Flagss 1145 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 1147 Address 1149 The Address field is four octets. The value 0xFFFFFFFF indicates 1150 that the NAS SHOULD allow the user to select an address. The value 1151 0 indicates that the NAS SHOULD select a host to connect the user 1152 to. Other values indicate the address the NAS SHOULD connect the 1153 user to. 1155 3.14. Login-Service 1157 Description 1159 This Attribute indicates the service which should be used to 1160 connect the user to the login host. It is only used in 1161 Authentication-Success messages. 1163 A summary of the Login-Service Attribute format is shown below. The 1164 fields are transmitted from left to right. 1166 0 1 2 3 1167 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 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 | AVP Code | 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 | AVP Length | AVP Flags | Reserved | 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 | Integer32 | 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 Type 1178 15 for Login-Service. 1180 AVP Length 1182 The length of this attribute MUST be 12. 1184 AVP Flagss 1186 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 1188 Integer32 1190 The Integer32 field is four octets. 1192 0 Telnet 1193 1 Rlogin 1194 2 TCP Clear 1195 3 PortMaster (proprietary) 1196 4 LAT 1198 3.15. Login-TCP-Port 1200 Description 1202 This Attribute indicates the TCP port with which the user is to be 1203 connected, when the Login-Service Attribute is also present. It is 1204 only used in Authentication-Success packets. 1206 A summary of the Login-TCP-Port Attribute format is shown below. 1207 The fields are transmitted from left to right. 1209 0 1 2 3 1210 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 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 | AVP Code | 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 | AVP Length | AVP Flags | Reserved | 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 | Integer32 | 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 Type 1221 16 for Login-TCP-Port. 1223 AVP Length 1225 The length of this attribute MUST be 12. 1227 AVP Flagss 1229 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 1231 Integer32 1233 The Integer32 field is four octets. Despite the size of the field, 1234 values range from 0 to 65535. 1236 3.16. Reply-Message 1238 Description 1240 This Attribute indicates text which MAY be displayed to the user. 1242 When used in an Authentication-Success, it is the success message. 1244 When used in an Authentication-Failure, it is the failure message. 1245 It MAY indicate a dialog message to prompt the user before another 1246 Authentication-Request attempt. 1248 When used in an Authentication-Challenge, it MAY indicate a dialog 1249 message to prompt the user for a response. 1251 Multiple Reply-Message's MAY be included and if any are displayed, 1252 they MUST be displayed in the same order as they appear in the 1253 packet. 1255 A summary of the Reply-Message Attribute format is shown below. The 1256 fields are transmitted from left to right. 1258 0 1 2 3 1259 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 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | AVP Code | 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | AVP Length | AVP Flags | Reserved | 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 | String ... 1266 +-+-+-+-+-+-+-+-+ 1268 Type 1270 18 for Reply-Message. 1272 AVP Length 1274 The length of this attribute MUST be at least 9. 1276 AVP Flagss 1278 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 1280 String 1282 The String field is one or more octets, and its contents are 1283 implementation dependent. It is intended to be human readable, and 1284 MUST NOT affect operation of the protocol. It is recommended that 1285 the message contain displayable ASCII characters from the range 10, 1286 13, and 32 through 126 decimal. Mechanisms for extension to other 1287 character sets are beyond the scope of this specification. 1289 3.17. Callback-Number 1291 Description 1293 This Attribute indicates a dialing string to be used for callback. 1294 It MAY be used in Authentication-Success packets. It MAY be used in 1295 an Authentication-Request packet as a hint to the server that a 1296 Callback service is desired, but the server is not required to 1297 honor the hint. 1299 A summary of the Callback-Number Attribute format is shown below. 1300 The fields are transmitted from left to right. 1302 0 1 2 3 1303 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 1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 | AVP Code | 1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 | AVP Length | AVP Flags | Reserved | 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 | String ... 1310 +-+-+-+-+-+-+-+-+ 1312 Type 1314 19 for Callback-Number. 1316 AVP Length 1318 The length of this attribute MUST be at least 9. 1320 AVP Flagss 1322 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 1324 String 1326 The String field is one or more octets. The actual format of the 1327 information is site or application specific, and a robust 1328 implementation SHOULD support the field as undistinguished octets. 1330 The codification of the range of allowed usage of this field is 1331 outside the scope of this specification. 1333 3.18. Callback-Id 1335 Description 1337 This Attribute indicates the name of a place to be called, to be 1338 interpreted by the NAS. It MAY be used in Authentication-Success 1339 messages. 1341 A summary of the Callback-Id Attribute format is shown below. The 1342 fields are transmitted from left to right. 1344 0 1 2 3 1345 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 1346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1347 | AVP Code | 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1349 | AVP Length | AVP Flags | Reserved | 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 | String ... 1352 +-+-+-+-+-+-+-+-+ 1354 Type 1356 20 for Callback-Id. 1358 AVP Length 1360 The length of this attribute MUST be at least 9. 1362 AVP Flagss 1364 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 1366 String 1368 The String field is one or more octets. The actual format of the 1369 information is site or application specific, and a robust 1370 implementation SHOULD support the field as undistinguished octets. 1371 The codification of the range of allowed usage of this field is 1372 outside the scope of this specification. 1374 3.19. Framed-Route 1376 Description 1378 This Attribute provides routing information to be configured for 1379 the user on the NAS. It is used in the Authentication-Success 1380 message and can appear multiple times. 1382 A summary of the Framed-Route Attribute format is shown below. The 1383 fields are transmitted from left to right. 1385 0 1 2 3 1386 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 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 | AVP Code | 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 | AVP Length | AVP Flags | Reserved | 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 | String ... 1393 +-+-+-+-+-+-+-+-+ 1395 Type 1397 22 for Framed-Route. 1399 AVP Length 1401 The length of this attribute MUST be at least 9. 1403 AVP Flagss 1405 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 1407 String 1409 The String field is one or more octets, and its contents are 1410 implementation dependent. It is intended to be human readable and 1411 MUST NOT affect operation of the protocol. It is recommended that 1412 the message contain displayable ASCII characters from the range 32 1413 through 126 decimal. 1415 For IP routes, it SHOULD contain a destination prefix in dotted 1416 quad form optionally followed by a slash and a decimal length 1417 specifier stating how many high order bits of the prefix should be 1418 used. That is followed by a space, a gateway address in dotted quad 1419 form, a space, and one or more metrics separated by spaces. For 1420 example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length 1421 specifier may be omitted in which case it should default to 8 bits 1422 for class A prefixes, 16 bits for class B prefixes, and 24 bits for 1423 class C prefixes. For example, "192.168.1.0 192.168.1.1 1". 1425 Whenever the gateway address is specified as "0.0.0.0" the IP 1426 address of the user SHOULD be used as the gateway address. 1428 3.20. Framed-IPX-Network 1430 Description 1432 This Attribute indicates the IPX Network number to be configured 1433 for the user. It is used in Authentication-Success messages. 1435 A summary of the Framed-IPX-Network Attribute format is shown 1436 below. The fields are transmitted from left to right. 1438 0 1 2 3 1439 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 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 | AVP Code | 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 | AVP Length | AVP Flags | Reserved | 1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1445 | Integer32 | 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 Type 1450 23 for Framed-IPX-Network. 1452 AVP Length 1454 The length of this attribute MUST be 12. 1456 AVP Flagss 1458 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 1460 Integer32 1462 The Integer32 field is four octets. The value 0xFFFFFFFF indicates 1463 that the NAS should allow the user to select an address (e.g. 1464 Negotiated). The value 0xFFFFFFFE indicates that the NAS should 1465 select an address for the user (e.g. assigned from a pool of one or 1466 more IPX networks kept by the NAS) Other values should be used as 1467 the IPX network for the link to the user. 1469 3.21. State 1471 Description 1473 This Attribute is available to be sent by the server to the client 1474 in an Authentication-Challenge and MUST be sent unmodified from the 1475 client to the server in the new Authentication-Request reply to 1476 that challenge, if any. 1478 In either usage, no interpretation by the client should be made. A 1479 packet may have only one State Attribute. Usage of the State 1480 Attribute is implementation dependent. 1482 A summary of the State Attribute format is shown below. The fields 1483 are transmitted from left to right. 1485 0 1 2 3 1486 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 1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1488 | AVP Code | 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1490 | AVP Length | AVP Flags | Reserved | 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 | Data ... 1493 +-+-+-+-+-+-+-+-+ 1495 Type 1497 24 for State. 1499 AVP Length 1501 The length of this attribute MUST be at least 9. 1503 AVP Flagss 1505 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 1507 String 1509 The String field is one or more octets. The actual format of the 1510 information is site or application specific, and a robust 1511 implementation SHOULD support the field as undistinguished octets. 1513 The codification of the range of allowed usage of this field is 1514 outside the scope of this specification. 1516 3.22. Class 1518 Description 1520 This Attribute is available to be sent by the server to the client 1521 in an Authentication-Success and should be sent unmodified by the 1522 client to the accounting server as part of the Accounting-Request 1523 message if accounting is supported. No interpretation by the client 1524 should be made. 1526 A summary of the Class Attribute format is shown below. The fields 1527 are transmitted from left to right. 1529 0 1 2 3 1530 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 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 | AVP Code | 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 | AVP Length | AVP Flags | Reserved | 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 | Data ... 1537 +-+-+-+-+-+-+-+-+ 1539 Type 1541 25 for Class. 1543 AVP Length 1545 The length of this attribute MUST be at least 9. 1547 AVP Flagss 1549 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 1551 String 1553 The String field is one or more octets. The actual format of the 1554 information is site or application specific, and a robust 1555 implementation SHOULD support the field as undistinguished octets. 1557 The codification of the range of allowed usage of this field is 1558 outside the scope of this specification. 1560 3.23. Vendor-Specific 1562 Description 1564 This AVP is not supported in DIAMETER. Vendor Specific Attributes 1565 are used by enabling the Vendor-Specific bit in the AVP header. 1567 3.24. Session-Timeout 1569 Description 1571 This Attribute sets the maximum number of seconds of service to be 1572 provided to the user before termination of the session or prompt. 1573 This Attribute is available to be sent by the server to the client 1574 in an Authentication-Success or Authentication-Challenge. 1576 A summary of the Session-Timeout Attribute format is shown below. 1577 The fields are transmitted from left to right. 1579 0 1 2 3 1580 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 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 | AVP Code | 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 | AVP Length | AVP Flags | Reserved | 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 | Integer32 | 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 Type 1591 27 for Session-Timeout. 1593 AVP Length 1595 The length of this attribute MUST be 12. 1597 AVP Flagss 1599 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 1601 Integer32 1603 The Integer32 field is 4 octets, containing a 32-bit unsigned 1604 integer with the maximum number of seconds this user should be 1605 allowed to remain connected by the NAS. 1607 3.25. Idle-Timeout 1608 Description 1610 This Attribute sets the maximum number of consecutive seconds of 1611 idle connection allowed to the user before termination of the 1612 session or prompt. This Attribute is available to be sent by the 1613 server to the client in an Authentication-Success or 1614 Authentication-Challenge. 1616 A summary of the Idle-Timeout Attribute format is shown below. The 1617 fields are transmitted from left to right. 1619 0 1 2 3 1620 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 1621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1622 | AVP Code | 1623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1624 | AVP Length | AVP Flags | Reserved | 1625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1626 | Integer32 | 1627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 Type 1631 28 for Idle-Timeout. 1633 AVP Length 1635 The length of this attribute MUST be 12. 1637 AVP Flagss 1639 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 1641 Integer32 1643 The Integer32 field is 4 octets, containing a 32-bit unsigned 1644 integer with the maximum number of consecutive seconds of idle time 1645 this user should be permitted before being disconnected by the NAS. 1647 3.26. Termination-Action 1649 Description 1651 This Attribute is not supported in DIAMETER. 1653 3.27. Called-Station-Id 1655 Description 1656 This Attribute allows the NAS to send in the Authentication-Request 1657 message the phone number that the user called, using Dialed Number 1658 Identification (DNIS) or similar technology. Note that this may be 1659 different from the phone number the call comes in on. It is only 1660 used in Authentication-Request packets. 1662 If the Authorization-Only flag is set in the message and the User- 1663 Name AVP is absent, the DIAMETER Server MUST perform authorization 1664 based on this field. This can be used by a NAS to request whether a 1665 call should be answered based on the DNIS. 1667 A summary of the Called-Station-Id Attribute format is shown below. 1668 The fields are transmitted from left to right. 1670 0 1 2 3 1671 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 1672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1673 | AVP Code | 1674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1675 | AVP Length | AVP Flags | Reserved | 1676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1677 | String ... 1678 +-+-+-+-+-+-+-+-+ 1680 Type 1682 30 for Called-Station-Id. 1684 AVP Length 1686 The length of this attribute MUST be at least 9. 1688 AVP Flagss 1690 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 1692 String 1694 The String field is one or more octets, containing the phone number 1695 that the user's call came in on. 1697 The actual format of the information is site or application 1698 specific. Printable ASCII is recommended, but a robust 1699 implementation SHOULD support the field as undistinguished octets. 1701 The codification of the range of allowed usage of this field is 1702 outside the scope of this specification. 1704 3.28. Calling-Station-Id 1705 Description 1707 This Attribute allows the NAS to send in the Authentication-Request 1708 packet the phone number that the call came from, using Automatic 1709 Number Identification (ANI) or similar technology. It is only used 1710 in Authentication-Request packets. 1712 If the Authorization-Only flag is set in the message and the User- 1713 Name AVP is absent, the DIAMETER Server must perform authorization 1714 based on this field. This can be used by a NAS to request whether a 1715 call should be answered based on the ANI. 1717 A summary of the Calling-Station-Id Attribute format is shown 1718 below. The fields are transmitted from left to right. 1720 0 1 2 3 1721 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 1722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1723 | AVP Code | 1724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1725 | AVP Length | AVP Flags | Reserved | 1726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1727 | String ... 1728 +-+-+-+-+-+-+-+-+ 1730 Type 1732 31 for Calling-Station-Id. 1734 AVP Length 1736 The length of this attribute MUST be at least 9. 1738 AVP Flagss 1740 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 1742 String 1744 The String field is one or more octets, containing the phone number 1745 that the user placed the call from. 1747 The actual format of the information is site or application 1748 specific. Printable ASCII is recommended, but a robust 1749 implementation SHOULD support the field as undistinguished octets. 1751 The codification of the range of allowed usage of this field is 1752 outside the scope of this specification. 1754 3.29. Proxy-State 1756 Description 1758 This Attribute is available to be sent by a proxy server to another 1759 server when forwarding an Authentication-Request and MUST be 1760 returned unmodified in the Authentication-Success, Authentication- 1761 Failure or Authentication-Challenge. This attribute should be 1762 removed by the proxy server before the response is forwarded to the 1763 NAS. 1765 A summary of the Proxy-State Attribute format is shown below. The 1766 fields are transmitted from left to right. 1768 0 1 2 3 1769 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 1770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1771 | AVP Code | 1772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1773 | AVP Length | AVP Flags | Reserved | 1774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1775 | Data ... 1776 +-+-+-+-+-+-+-+-+ 1778 Type 1780 33 for Proxy-State. 1782 AVP Length 1784 The length of this attribute MUST be at least 9. 1786 AVP Flagss 1788 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 1790 String 1792 The String field is one or more octets. The actual format of the 1793 information is site or application specific, and a robust 1794 implementation SHOULD support the field as undistinguished octets. 1796 The codification of the range of allowed usage of this field is 1797 outside the scope of this specification. 1799 3.30. Login-LAT-Service 1801 Description 1802 This Attribute indicates the system with which the user is to be 1803 connected by LAT. It MAY be used in Authentication-Success packets, 1804 but only when LAT is specified as the Login-Service. It MAY be used 1805 in an Authentication-Request packet as a hint to the server, but 1806 the server is not required to honor the hint. 1808 Administrators use the service attribute when dealing with 1809 clustered systems, such as a VAX or Alpha cluster. In such an 1810 environment several different time sharing hosts share the same 1811 resources (disks, printers, etc.), and administrators often 1812 configure each to offer access (service) to each of the shared 1813 resources. In this case, each host in the cluster advertises its 1814 services through LAT broadcasts. 1816 Sophisticated users often know which service providers (machines) 1817 are faster and tend to use a node name when initiating a LAT 1818 connection. Alternately, some administrators want particular users 1819 to use certain machines as a primitive form of load balancing 1820 (although LAT knows how to do load balancing itself). 1822 A summary of the Login-LAT-Service Attribute format is shown below. 1823 The fields are transmitted from left to right. 1825 0 1 2 3 1826 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 1827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1828 | AVP Code | 1829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1830 | AVP Length | AVP Flags | Reserved | 1831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1832 | String ... 1833 +-+-+-+-+-+-+-+-+ 1835 Type 1837 34 for Login-LAT-Service. 1839 AVP Length 1841 The length of this attribute MUST be at least 9. 1843 AVP Flagss 1845 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 1847 String 1849 The String field is one or more octets, and contains the identity 1850 of the LAT service to use. The LAT Architecture allows this string 1851 to contain $ (dollar), - (hyphen), . (period), _ (underscore), 1852 numerics, upper and lower case alphabetics, and the ISO Latin-1 1853 character set extension [6]. All LAT string comparisons are case 1854 insensitive. 1856 3.31. Login-LAT-Node 1858 Description 1860 This Attribute indicates the Node with which the user is to be 1861 automatically connected by LAT. It MAY be used in Authentication- 1862 Success packets, but only when LAT is specified as the Login- 1863 Service. It MAY be used in an Authentication-Request packet as a 1864 hint to the server, but the server is not required to honor the 1865 hint. 1867 A summary of the Login-LAT-Node Attribute format is shown below. 1868 The fields are transmitted from left to right. 1870 0 1 2 3 1871 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 1872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1873 | AVP Code | 1874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1875 | AVP Length | AVP Flags | Reserved | 1876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1877 | String ... 1878 +-+-+-+-+-+-+-+-+ 1880 Type 1882 35 for Login-LAT-Node. 1884 AVP Length 1886 The length of this attribute MUST be at least 9. 1888 AVP Flagss 1890 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 1892 String 1894 The String field is one or more octets, and contains the identity 1895 of the LAT Node to connect the user to. The LAT Architecture allows 1896 this string to contain $ (dollar), - (hyphen), . (period), _ 1897 (underscore), numerics, upper and lower case alphabetics, and the 1898 ISO Latin-1 character set extension. All LAT string comparisons are 1899 case insensitive. 1901 3.32. Login-LAT-Group 1903 Description 1905 This Attribute contains a string identifying the LAT group codes 1906 which this user is authorized to use. It MAY be used in 1907 Authentication-Success packets, but only when LAT is specified as 1908 the Login-Service. It MAY be used in an Authentication-Request 1909 packet as a hint to the server, but the server is not required to 1910 honor the hint. 1912 LAT supports 256 different group codes, which LAT uses as a form of 1913 access rights. LAT encodes the group codes as a 256 bit bitmap. 1915 Administrators can assign one or more of the group code bits at the 1916 LAT service provider; it will only accept LAT connections that have 1917 these group codes set in the bit map. The administrators assign a 1918 bitmap of authorized group codes to each user; LAT gets these from 1919 the operating system, and uses these in its requests to the service 1920 providers. 1922 A summary of the Login-LAT-Group Attribute format is shown below. 1923 The fields are transmitted from left to right. 1925 0 1 2 3 1926 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 1927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1928 | AVP Code | 1929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1930 | AVP Length | AVP Flags | Reserved | 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 | Data ... 1933 +-+-+-+-+-+-+-+-+ 1935 Type 1937 36 for Login-LAT-Group. 1939 AVP Length 1941 The length of this attribute MUST be 40. 1943 AVP Flagss 1945 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 1947 Data 1949 The Data field is a 32 octet bit map, most significant octet first. 1950 A robust implementation SHOULD support the field as undistinguished 1951 octets. 1953 The codification of the range of allowed usage of this field is 1954 outside the scope of this specification. 1956 3.33. Framed-AppleTalk-Link 1958 Description 1960 This Attribute indicates the AppleTalk network number which should 1961 be used for the serial link to the user, which is another AppleTalk 1962 router. It is only used in Authentication-Success packets. It is 1963 never used when the user is not another router. 1965 A summary of the Framed-AppleTalk-Link Attribute format is shown 1966 below. The fields are transmitted from left to right. 1968 0 1 2 3 1969 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 1970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1971 | AVP Code | 1972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1973 | AVP Length | AVP Flags | Reserved | 1974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1975 | Integer32 | 1976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1978 Type 1980 37 for Framed-AppleTalk-Link. 1982 AVP Length 1984 The length of this attribute MUST be 12. 1986 AVP Flagss 1988 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 1990 Integer32 1992 The Integer32 field is four octets. Despite the size of the field, 1993 values range from 0 to 65535. The special value of 0 indicates that 1994 this is an unnumbered serial link. A value of 1-65535 means that 1995 the serial line between the NAS and the user should be assigned 1996 that value as an AppleTalk network number. 1998 3.34. Framed-AppleTalk-Network 1999 Description 2001 This Attribute indicates the AppleTalk Network number which the NAS 2002 should probe to allocate an AppleTalk node for the user. It is only 2003 used in Authentication-Success packets. It is never used when the 2004 user is another router. Multiple instances of this Attribute 2005 indicate that the NAS may probe using any of the network numbers 2006 specified. 2008 A summary of the Framed-AppleTalk-Network Attribute format is shown 2009 below. The fields are transmitted from left to right. 2011 0 1 2 3 2012 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 2013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2014 | AVP Code | 2015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2016 | AVP Length | AVP Flags | Reserved | 2017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2018 | Integer32 | 2019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2021 Type 2023 38 for Framed-AppleTalk-Network. 2025 AVP Length 2027 The length of this attribute MUST be 12. 2029 AVP Flagss 2031 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 2033 Integer32 2035 The Integer32 field is four octets. Despite the size of the field, 2036 values range from 0 to 65535. The special value 0 indicates that 2037 the NAS should assign a network for the user, using its default 2038 cable range. A value between 1 and 65535 (inclusive) indicates the 2039 AppleTalk Network the NAS should probe to find an address for the 2040 user. 2042 3.35. Framed-AppleTalk-Zone 2044 Description 2046 This Attribute indicates the AppleTalk Default Zone to be used for 2047 this user. It is only used in Authentication-Success packets. 2049 Multiple instances of this attribute in the same packet are not 2050 allowed. 2052 A summary of the Framed-AppleTalk-Zone Attribute format is shown 2053 below. The fields are transmitted from left to right. 2055 0 1 2 3 2056 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 2057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2058 | AVP Code | 2059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2060 | AVP Length | AVP Flags | Reserved | 2061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2062 | Data ... 2063 +-+-+-+-+-+-+-+-+ 2065 Type 2067 39 for Framed-AppleTalk-Zone. 2069 AVP Length 2071 The length of this attribute MUST be at least 9. 2073 AVP Flagss 2075 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 2077 String 2079 The name of the Default AppleTalk Zone to be used for this user. A 2080 robust implementation SHOULD support the field as undistinguished 2081 octets. 2083 The codification of the range of allowed usage of this field is 2084 outside the scope of this specification. 2086 3.36. CHAP-Challenge 2088 Description 2090 This Attribute contains the CHAP Challenge sent by the NAS to a PPP 2091 Challenge-Handshake Authentication Protocol (CHAP) user. It is only 2092 used in Authentication-Request packets. 2094 A summary of the CHAP-Challenge Attribute format is shown below. 2095 The fields are transmitted from left to right. 2097 0 1 2 3 2098 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 2099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2100 | AVP Code | 2101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2102 | AVP Length | AVP Flags | Reserved | 2103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2104 | Data ... 2105 +-+-+-+-+-+-+-+-+ 2107 Type 2109 60 for CHAP-Challenge. 2111 AVP Length 2113 The length of this attribute MUST be at least 24. 2115 AVP Flagss 2117 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 2119 Data 2121 The Data field contains the CHAP Challenge. 2123 3.37. NAS-Port-Type 2125 Description 2127 This Attribute indicates the type of the physical port of the NAS 2128 which is authenticating the user. It can be used instead of or in 2129 addition to the NAS-Port (5) attribute. It is only used in 2130 Authentication-Request packets. Either NAS-Port (5) or NAS-Port- 2131 Type or both SHOULD be present in an Authentication-Request packet, 2132 if the NAS differentiates among its ports. 2134 A summary of the NAS-Port-Type Attribute format is shown below. The 2135 fields are transmitted from left to right. 2137 0 1 2 3 2138 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 2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2140 | AVP Code | 2141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2142 | AVP Length | AVP Flags | Reserved | 2143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2144 | Integer32 | 2145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2147 Type 2149 61 for NAS-Port-Type. 2151 AVP Length 2153 The length of this attribute MUST be 12. 2155 AVP Flagss 2157 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 2159 Integer32 2161 The Integer32 field is four octets. "Virtual" refers to a 2162 connection to the NAS via some transport protocol, instead of 2163 through a physical port. For example, if a user telnetted into a 2164 NAS to authenticate himself as an Outbound-User, the 2165 Authentication-Request might include NAS-Port-Type = Virtual as a 2166 hint to the RADIUS server that the user was not on a physical port. 2168 0 Async 2169 1 Sync 2170 2 ISDN Sync 2171 3 ISDN Async V.120 2172 4 ISDN Async V.110 2173 5 Virtual 2175 3.38. Port-Limit 2177 Description 2179 This Attribute sets the maximum number of ports to be provided to 2180 the user by the NAS. This Attribute MAY be sent by the server to 2181 the client in an Authentication-Success packet. It is intended for 2182 use in conjunction with Multilink PPP [7] or similar uses. It MAY 2183 also be sent by the NAS to the server as a hint that that many 2184 ports are desired for use, but the server is not required to honor 2185 the hint. 2187 A summary of the Port-Limit Attribute format is shown below. The 2188 fields are transmitted from left to right. 2190 0 1 2 3 2191 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 2192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2193 | AVP Code | 2194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2195 | AVP Length | AVP Flags | Reserved | 2196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2197 | Integer32 | 2198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2200 Type 2202 62 for Port-Limit. 2204 AVP Length 2206 The length of this attribute MUST be 12. 2208 AVP Flagss 2210 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 2212 Integer32 2214 The Integer32 field is 4 octets, containing a 32-bit unsigned 2215 integer with the maximum number of ports this user should be 2216 allowed to connect to on the NAS. 2218 3.39. Login-LAT-Port 2220 Description 2222 This Attribute indicates the Port with which the user is to be 2223 connected by LAT. It MAY be used in Authentication-Success packets, 2224 but only when LAT is specified as the Login-Service. It MAY be used 2225 in an Authentication-Request packet as a hint to the server, but 2226 the server is not required to honor the hint. 2228 A summary of the Login-LAT-Port Attribute format is shown below. 2229 The fields are transmitted from left to right. 2231 0 1 2 3 2232 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 2233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2234 | AVP Code | 2235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2236 | AVP Length | AVP Flags | Reserved | 2237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2238 | String ... 2239 +-+-+-+-+-+-+-+-+ 2241 Type 2243 63 for Login-LAT-Port. 2245 AVP Length 2247 The length of this attribute MUST be at least 9. 2249 AVP Flagss 2251 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 2253 String 2255 The String field is one or more octets, and contains the identity 2256 of the LAT port to use. The LAT Architecture allows this string to 2257 contain $ (dollar), - (hyphen), . (period), _ (underscore), 2258 numerics, upper and lower case alphabetics, and the ISO Latin-1 2259 character set extension. All LAT string comparisons are case 2260 insensitive. 2262 3.40. Framed-Password-Policy 2264 Description 2266 This Attribute is used to indicate to a peer what types of 2267 authentication are supported by the issuing DIAMETER peer. More 2268 than one Framed-Password-Policy AVP MAY be present in the Domain- 2269 Discovery-Response message. 2271 A summary of the User-Name Attribute format is shown below. The 2272 fields are transmitted from left to right. 2274 0 1 2 3 2275 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 2276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2277 | AVP Code | 2278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2279 | AVP Length | AVP Flags | Reserved | 2280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2281 | Integer32 | 2282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2284 Type 2286 268 for Framed-Password-Policy. 2288 AVP Length 2290 The length of this attribute MUST be 12. 2292 AVP Flagss 2293 The AVP Flags field MUST have bit 1 (Mandatory Support) set. 2295 Integer32 2297 The Integer32 field contains the supported authentication schemes 2298 supported. The following values are supported: 2300 PAP 1 2301 CHAP 2 2302 MS-CHAP 3 2303 EAP 4 2304 SPAP 5 2306 3.41. Table of Attributes 2308 The following table provides a guide to which attributes may be found 2309 in which kinds of packets, and in what quantity. 2311 Req Succ Fail Chal Disc-Req Disc-Rsp # Attribute 2312 0-1 0-1 0 0 1 0-1 1 User-Name 2313 0-1 0 0 0 0 0 2 User-Password [*1] 2314 0-1 0 0 0 0 0 3 CHAP-Password [*1] 2315 0-1 0 0 0 0 0 4 NAS-IP-Address 2316 0-1 0 0 0 0 0 5 NAS-Port 2317 0-1 0-1 0 0 0 0 6 Service-Type 2318 0-1 0-1 0 0 0 0 7 Framed-Protocol 2319 0-1 0-1 0 0 0 0 8 Framed-IP-Address 2320 0-1 0-1 0 0 0 0 9 Framed-IP-Netmask 2321 0 0-1 0 0 0 0 10 Framed-Routing 2322 0 0+ 0 0 0 0 11 Filter-Id 2323 0 0-1 0 0 0 0 12 Framed-MTU 2324 0+ 0+ 0 0 0 0 13 Framed-Compression 2325 0+ 0+ 0 0 0 0 14 Login-IP-Host 2326 0 0-1 0 0 0 0 15 Login-Service 2327 0 0-1 0 0 0 0 16 Login-TCP-Port 2328 0 0+ 0+ 0+ 0 0 18 Reply-Message 2329 0-1 0-1 0 0 0 0 19 Callback-Number 2330 0 0-1 0 0 0 0 20 Callback-Id 2331 0 0+ 0 0 0 0 22 Framed-Route 2332 0 0-1 0 0 0 0 23 Framed-IPX-Network 2333 0-1 0-1 0 0-1 0 0 24 State 2334 0 0+ 0 0 0 0 25 Class 2335 0+ 0+ 0 0+ 0+ 0+ 26 Vendor-Specific 2336 0 0-1 0 0-1 0-1 0-1 27 Session-Timeout 2337 0 0-1 0 0-1 0-1 0-1 28 Idle-Timeout 2338 0 0-1 0 0 0 0 29 Termination-Action 2339 0-1 0 0 0 0 0 30 Called-Station-Id 2340 0-1 0 0 0 0 0 31 Calling-Station-Id 2341 0-1 0 0 0 0 0 32 NAS-Identifier 2342 0+ 0+ 0+ 0+ 0+ 0+ 33 Proxy-State 2343 0-1 0-1 0 0 0 0 34 Login-LAT-Service 2344 0-1 0-1 0 0 0 0 35 Login-LAT-Node 2345 0-1 0-1 0 0 0 0 36 Login-LAT-Group 2346 0 0-1 0 0 0 0 37 Framed-AppleTalk-Link 2347 0 0+ 0 0 0 0 38 Framed-AppleTalk-Net. 2348 0 0-1 0 0 0 0 39 Framed-AppleTalk-Zone 2349 0-1 0 0 0 0 0 60 CHAP-Challenge 2350 0-1 0 0 0 0 0 61 NAS-Port-Type 2351 0-1 0-1 0 0 0 0 62 Port-Limit 2352 0-1 0-1 0 0 0 0 63 Login-LAT-Port 2353 0-1 0-1 0 0 0 0+ 268 Framed-Password-Pol. 2354 Req Succ Fail Chal Disc-Req Disc-Rsp # Attribute 2356 [*1] An Authentication-Request MUST NOT contain both a User- 2357 Password and a CHAP-Password AVP. 2359 The following table defines the meaning of the above table entries. 2361 0 This attribute MUST NOT be present in packet. 2362 0+ Zero or more instances of this attribute MAY be present 2363 in packet. 2364 0-1 Zero or one instance of this attribute MAY be present 2365 in packet. 2366 1 Exactly one instance of this attribute MUST be present in 2367 packet. 2369 4.0 Protocol Definition 2371 This section will outline how the DIAMETER Authentication Extension 2372 can be used. 2374 4.1 RADIUS Proxies 2376 In today's dial up networks the RADIUS protocol is used to 2377 authentication, authorize and perform accounting for dial-up users. 2378 However, it has become common practice to make use of RADIUS Servers 2379 known as proxies. 2381 The use of proxies has become widespread especially with the 2382 popularity of Internet Roaming[4]. In this example a user has a single 2383 user account with a local service provider. When this user roams 2384 outside of his ISPs service area, it is possible for the user to 2385 connect to another service provider (see [4] for more details). 2387 In this scenario, the new service provider (ISPB) provides internet 2388 access for the user through a NAS (NASB). ISPB owns an authentication 2389 server (RADB), which proxies the authentication request to the user's 2390 original provider's authentication server (RADA). 2392 (Access-Request) (Access-Request) 2393 +------+ -----> +------+ ------> +------+ 2394 | | | | | | 2395 | NASB +--------------------+ RADB +--------------------+ RADA + 2396 | | | | | | 2397 +------+ <----- +------+ <------ +------+ 2398 (Access-Accept) (Access-Accept) 2400 The example shown above NASB generates an authentication request on 2401 behalf of the dial-in user to the RADB Authentication server. In this 2402 case, the user's identity would include a domain identifier [3] that 2403 would enable RADB to identify the authentication server (i.e. 2404 user@ISPA.com). 2406 The RADB server then forwards the request to RADA which authenticates 2407 the user based on information found within the request. If 2408 successfully authentication the RADA server returns a successful 2409 response along with authorization information. If the user 2410 authentication fails RADA replies with a failed response. 2412 In the past this model has caused much concern over it's security 2413 implication. The model is much worse in the model where there exists 2414 an intermediate provider between ISPB and ISPA (say ISPC). The 2415 following diagram depicts such an example where RADB must forward any 2416 requests for RADA through RADC. 2418 (Accounting-Request) (Accounting-Request) 2419 +------+ -----> +------+ ------> +------+ 2420 | | | | | | 2421 | RADB +--------------------+ RADC +--------------------+ RADA + 2422 | | | | | | 2423 +------+ <----- +------+ <------ +------+ 2424 (Accounting-Response) (Accounting-Response) 2426 The problem with the above scenario is that complete trust is placed 2427 in RADC (and hence ISPC) since it is very simple to modify any 2428 attributes found within the request or the response. The example shows 2429 an accounting request sent from RADB to RADA through RADC. The 2430 following is a list of a few attacks which can be generated by a 2431 malicious proxy: 2433 - Generating Accounting Records by replaying old 2434 authentication/accounting records. In this example it is very 2435 simple for RADC to simple retain old packets and replay then at a 2436 later date. This will cause RADA to "pay" for services which were 2437 never rendered. 2439 - Modify Attributes within the request or response. In this case 2440 RADC can modify attributes, such as the length of the call, that 2441 would fool RADA into believing the call was longer than in reality. 2443 - Stealing PAP Passwords is another problem with today's proxies. 2444 In the current model PAP passwords are encrypted using a shared 2445 secret which is shared between each hop in the proxy chain. In this 2446 case each hop has the opportunity to decrypt, and possibly save for 2447 future use, the user's password. 2449 Given the problems identified above with the current proxy model it is 2450 necessary to create a mechanism which allows for non-repudiation, end- 2451 to-end data integrity as well as end-to-end encryption. Given the 2452 current encryption technology this can only be achieved with the use 2453 of asymetric encryption and digital signatures. 2455 4.2 DIAMETER Proxies 2457 The DIAMETER protocol also makes use of proxies in order to keep the 2458 existing arrangements while migrating from RADIUS to DIAMETER. However 2459 since DIAMETER makes use of asymetric encryption and digital 2460 signatures it solves many of the problems shown above. 2462 (Authentication-Request) (Authentication-Request) 2463 +------+ -----> +------+ ------> +------+ 2464 | | | | | | 2465 | NASB +--------------------+ DIA2 +--------------------+ DIA1 + 2466 | | | | | | 2467 +------+ <----- +------+ <------ +------+ 2468 (Authentication-Response) (Authentication-Response) 2470 In this example NASB generates an Authentication-Request that is 2471 forwarded to DIA2. The Authentication-Request contains a digital 2472 signature AVP which "protects" all mandatory (or non-editable) AVPs 2473 within the request. All AVPs which may be modified, or removed appear 2474 after the digital signature AVP. Once DIA2 receives the request, it 2475 MAY authenticate the request to ensure that it was originated by NASB 2476 (verifying the signature is not necessary if the link between NASB and 2477 DIA2 is secured using IPSEC). 2479 The DIA2 Server may then add new attributes to the request. All 2480 mandatory AVPs MUST be present prior to the non mandatory AVPs and 2481 MUST be preceeded by a Digital Signature AVP (using DIA2's private 2482 key). Note that all non-mandatory AVPs added to the packet by NASB 2483 must appear after DIA2's digital signature AVP. The message is then 2484 forwarded towards the DIA1 server. 2486 Since all packets between NASB and DIA1 must flow through DIA2, it is 2487 not possible to use IPSEC between both hosts. Therefore DIA1 MUST 2488 validate NASB's digital signature AVP. However it is not necessary to 2489 validate DIA2's digital signature if the link between DIA2 and DIA1 is 2490 secured using IPSEC. 2492 This mechanism now provides a method for DIA1 to prove that NASB was 2493 the initiator of the request (note that DIAMETER also includes a 2494 timestap to prevent replay attacks). It also provides a method of 2495 ensuring that DIA2 cannot modify any "non-editable" attributes (such 2496 as length of call, etc). 2498 In addition, this same mechanism can be used for end to end encryption 2499 of AVPs. In the case where NASB needs to encrypt an AVP it is done 2500 using asymetric encryption using DIA1's public key. This ensures that 2501 only DIA1 can decrypt the AVP. 2503 An attack has been identified in this proposal which allows a malicous 2504 man in the middle attack as shown in the following diagram. 2506 (Auth-Request) (Auth-Request) (Auth-Request) 2507 +------+ -----> +------+ -----> +------+ -----> +------+ 2508 | | | | | | | | 2509 | NASB +----------+ DIA2 +----------+ DIA3 +----------+ DIA1 + 2510 | | | | | | | | 2511 +------+ <----- +------+ <----- +------+ <----- +------+ 2512 (Auth-Response) (Auth-Response) (Auth-Response) 2514 In this example, DIA3 traps packets generated from DIA2 towards DIA1, 2515 removes the AVPs added by DIA2 and inserts its own AVPs (posibly by 2516 trying to convince DIA1 to pay DIA3 for the services). This attack can 2517 be prevented by supporting a new Next-Hop AVP. In this case when NASB 2518 prepares a request it inserts a non-editable Next-Hop AVP which 2519 contains DIA2's identitity. DIA2 also adds a Next-Hop AVP with DIA1 as 2520 the next hop. 2522 This mechanism ensures that a man in the middle cannot alter the 2523 packet by overriding the previous hop's additions and signature. DIA1 2524 could easily validate the packet's path with the use of the Next-Hop 2525 AVPs. 2527 4.3 Domain Discovery 2529 The Domain Discovery message set is very useful in determining the 2530 Home authentication server, the password policies for the domain, as a 2531 mechanism to retrieve a certificate (or a pointer to a certificate). 2533 The following example shows a case where DIA1 needs to communicate 2534 with DIA3. In this example it is necessary to use DIA2 as a proxy in 2535 order for both ISPs to communicate. Although this MAY be desireable in 2536 some business models, there are cases where it is beneficial to remove 2537 the proxy altogether and allow both DIA3 and DIA1 to communicate in a 2538 secure fashion. 2540 (DD-Request) (DD-Request) 2542 +------+ -----> +------+ ------> +------+ 2543 | | | | | | 2544 | DIA1 +--------------------+ DIA2 +--------------------+ DIA3 + 2545 | | | | | | 2546 +------+ <----- +------+ <------ +------+ 2547 (DD-Response) (DD-Response) 2549 The way the Domain Discovery works is that prior to sending out an 2550 authentication request DIA1 would issue a Domain Discovery message 2551 towards DIA2. This message is protected with the digital signature as 2552 well as the Next-Hop AVP. DIA2 would then forward the request to DIA3 2553 including the Next-Hop and the digital signature AVP. 2555 When DIA3 receives the request, it MUST save the certificate (or the 2556 pointer to the certificate) and respond back including the local 2557 password policy, DIA3's certificate, it's contact information (i.e. IP 2558 address) and protect the response with the digital signature. 2560 Note that in all cases the TimeStamp AVP is also present to ensure no 2561 reply packets are accepted. 2563 When DIA2 receives the packet, it must add the Next-Hop AVP as well as 2564 the digital signature AVP. When DIA1 receives the packet it then knows 2565 a direct route to communicate with DIA3 since the contact information 2566 is present in the response. The fact that both DIA1 and DIA3 can now 2567 communicate directly allows both peers to use IPSEC to protect the 2568 message exchange (note that it MAY be desirable to also use the 2569 digital signature in order to keep the information in the DIAMETER 2570 logs). 2572 (Authentication-Request) 2573 +------+ -----> +------+ 2574 | | | | 2575 | DIA1 +--------------------+ DIA3 + 2576 | | | | 2577 +------+ <----- +------+ 2578 (Authentication-Response) 2580 In addition, the password policy is also present which can indicate 2581 whether DIA3 is willing to accept CHAP, PAP or EAP authentication. 2583 Note that the Domain-Request/Response MAY include the Supported- 2584 Extension AVPs [2]. 2586 5.0 Acknowledgements 2588 The Author wishes to thank Carl Rigney since much of the text in the 2589 document was shamefully copied from [1] as well as the following 2590 people for their help in the development of this protocol: 2592 Nancy Greene, Ryan Moats 2594 6.0 References 2596 [1] Rigney, et alia, "RADIUS", RFC-2138, Livingston, April 1997 2597 [2] P. R. Calhoun, A. Rubens, "DIAMETER Base Protocol", 2598 draft-calhoun-diameter-00.txt, February 1998. 2599 [3] B. Aboba. "The Network Access Identifier." Internet-Draft, 2600 August 1997. 2601 [4] Aboba, Zorn, "Dialup Roaming Requirements", Internet-Draft, 2602 July 1997. 2603 [5] P. Calhoun, A. Rubens, B. Aboba, "DIAMETER Extensible 2604 Authentication Protocol Extensions", 2605 draft-calhoun-diameter-eap-01.txt, March 1998. 2606 [6] P. Calhoun, J. Haag, G. Zorn, "EAP Authentication for SOCKS 2607 Version 5", draft-ietf-aft-socks-eap-00.txt, March 1998. 2608 [7] B. Aboba, M. Beadles, "Network Address Identifier", 2609 draft-ietf-roamops-nai-10.txt, February 1998. 2611 7.0 Authors' Addresses 2613 Questions about this memo can be directed to: 2615 Pat R. Calhoun 2616 Technology Development 2617 Sun Microsystems, Inc. 2618 15 Network Circle 2619 Menlo Park, California, 94025 2620 USA 2622 Phone: 1-847-548-9587 2623 Fax: 1-650-786-6445 2624 E-mail: pcalhoun@toast.net