idnits 2.17.1 draft-calhoun-diameter-ipsec-policy-00.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 218 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 273 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 4 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 100: '...s scenario that the AAA protocol MUST...' RFC 2119 keyword, line 108: '... o MUST, SHALL, or MANDATORY ...' RFC 2119 keyword, line 111: '... o SHOULD or RECOMMEND -- Thi...' RFC 2119 keyword, line 114: '... o MAY or OPTIONAL -- This it...' RFC 2119 keyword, line 593: '...e Protocol field MUST be set to ISAKMP...' (10 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...' == (213 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '5' is defined on line 1481, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1485, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1488, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1490, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1495, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1498, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-00 -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 1825 (ref. '9') (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1700 (ref. '10') (Obsoleted by RFC 3232) -- No information found for draft-calhoun-diameter-auth - is the name correct? -- Possible downref: Normative reference to a draft: ref. '11' Summary: 14 errors (**), 0 flaws (~~), 15 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Sumit A. Vakil 3 Category: Standards Track 3Com Corporation 4 Title: draft-calhoun-diameter-ipsec-policy-00.txt Pat R. Calhoun 5 Date: March 1998 Sun Microsystems, Inc. 7 DIAMETER 8 IP Security Policy 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 The DIAMETER User Authentication/Authorization extension defines a 32 mechanism which is used by a Network Access Server (NAS) to 33 authenticate dial-up users. IP Security defines a mechanism of 34 establishing a secure link between two entities over a network. 36 This document defines a mechanism for DIAMETER to inform the NAS of 37 the security policies required for secure communication with a host. 39 Table of Contents 41 1.0 Introduction 42 1.1 Conventions 43 2.0 Operation 44 2.1 Login User 45 2.2 Tunneled User 46 3.0 Policy Building 47 4.0 Security Gateway Support 48 5.0 Attribute Format, Name and Code 49 6.0 RADIUS Attributes 50 6.1 Transform 51 6.2 Encryption-Algorithm 52 6.3 Authentication-Algorithm 53 6.4 Authentication-Method 54 6.5 SA-Life-Seconds 55 6.6 SA-Life-Kbs 56 6.7 DH-Group 57 6.8 Key-Length 58 6.9 Key-Round 59 6.10 Enapsulation-Mode 60 6.11 Local-Id 61 6.12 Remote-Id 62 6.13 SA-Destination 63 6.14 Policy 64 6.15 Next-Hop 65 6.16 SA-Direction 66 6.17 Anti-Replay 67 6.18 Table of Attributes 68 7.0 References 69 8.0 Author's Address 71 1.0 Introduction 73 DIAMETER is a proposed protocol for dial-up user authentication, 74 authorization and accounting. In the case of "login" or tunneled 75 users, where the NAS initiates a connection to a specified host on 76 behalf of the user [1][2], the authorization information returned in 77 the DIAMETER message contains the target host information. The only 78 current security mechanism used to secure the connection is to rely on 79 the source IP address of the target host (which is very weak 80 security). 82 The IP Security (IPSEC) protocol suite is used by entities in order to 83 communicate in a secure fashion over an untrusted network. In order 84 for the NAS to be able to establish a secure link with a destination 85 host or network it requires a set of security policies which defines 86 the target as well as the different transforms which are to be used 87 during the communication. These policies need to be pre-configured on 88 the NAS prior to establishing the secure link. 90 Since an ISPs users will connect to a variety of hosts over the 91 internet, it becomes very difficult to statically configure these 92 policies for every possible host which a dial-up user may need to 93 connect to. In the case of tunneling, where customers are outsourcing 94 their dial-up services to a service provider this becomes even more 95 complex. It would therefore be desirable to have this information 96 maintained by an AAA server. 98 The fact that ROAMOPS is creating standards to allow users to roam to 99 any service provider to get internet access complicates the problem 100 even further. It is clear in this scenario that the AAA protocol MUST 101 be able to download IPSEC Security Policies to a NAS. 103 1.1 Conventions 105 The following language conventions are used in the items of specifi- 106 cation in this document: 108 o MUST, SHALL, or MANDATORY -- This item is an absolute 109 requirement of the specification. 111 o SHOULD or RECOMMEND -- This item should generally be followed 112 for all but exceptional circumstances. 114 o MAY or OPTIONAL -- This item is truly optional and may be 115 followed or ignored according to the needs of the 116 implementor. 118 2.0 Operation 120 In this section we will examine two possible types of users. In the 121 first example we will describe a login user, and the second will 122 define how a tunneled user would use the extensions used in this 123 document. 125 2.1 Login User 127 In this section we will look an at example of a login user. The user, 128 named joe, dials into a NAS which authenticates the user with the 129 assistance of a local DIAMETER Server. The user's DIAMETER profile is 130 shown below: 132 joe Password = password 133 Service-Type = Login, 134 Login-Service = Telnet, 135 Login-IP-Host = 10.1.1.1, 136 Login-Port = 23 138 As the user's profile depicts, once the user is authenticated the NAS 139 will create a telnet session to target host 10.1.1.1 on behalf of the 140 user. In this case the NAS is used as a terminal server and sends all 141 of the user's asynchronous data to the target encapsulated within a 142 telnet session. 144 +-----+ 145 | | 146 +--| DIA | 147 +-----+ +-----+ | | | 148 | | PSTN | | | +-----+ 149 | Joe |------------| NAS |---| 150 | | | | | 151 +-----+ +-----+ | +-----+ 152 | | | 153 +--|Targ.| 154 | | 155 IP +-----+ 157 As stated above IPSEC is a mechanism used by the NAS and the target to 158 establish a secure telnet connection for the user. Traditionally the 159 NAS must have security policies defined locally which state that all 160 communication with the target host for the user must be secured, and 161 more importantly how secure the communication must be. 163 2.2 Tunneled User 165 Document [3] defines a protocol which is used by a NAS to "tunnel" all 166 PPP data from the user to a destination host. This encapsulation is 167 done in order to allow a user to connect to a destination network from 168 the internet as well as to allow multi-protocol over an IP network. 170 Document [2] defines RADIUS attributes which may be sent from the 171 DIAMETER Server to the NAS which contain tunneling information, such 172 as the target tunnel endpoint. 174 In this example we will examine a user named bill which dials into a 175 NAS which authenticates the user using a local DIAMETER Server. The 176 DIAMETER Server informs the NAS that tunneling must occur for the user 177 as shown in the user's profile below. 179 bill Password = password 180 Service-Type = Framed, 181 Framed-Protocol = PPP, 182 Framed-IP-Netmask = 255.255.255.255, 183 Framed-MTU = 1500, 184 Framed-IP-Address = 2.3.4.5 , 185 Tunnel-Type = L2TP, 186 Tunnel-Medium-Type = IP, 187 Tunnel-Server-Endpoint = 10.1.1.2, 188 Tunnel-Password = password 190 As the user's profile states, once the user is authenticated the NAS 191 will create an L2TP tunnel with the target tunnel endpoint 10.1.1.2. 192 Once the tunnel is established all PPP traffic will be encapsulated 193 and forwarded to the target. 195 +-----+ 196 | | 197 +--| DIA | 198 +-----+ +-----+ | | | 199 | | PSTN | | | +-----+ 200 | Bill|------------| NAS |---| 201 | | | | | 202 +-----+ +-----+ | +-----+ 203 | | | 204 +--|Targ.| 205 | | 206 IP +-----+ 208 As stated above IPSEC is a mechanism used by the NAS and the target to 209 establish a secure tunnel for the user. Traditionally the NAS must 210 have security policies defined locally which state that all 211 communication with the target host for the user must be secured, and 212 more importantly how secure the communication must be. 214 3.0 Policy Building 215 This section will define how Policies are built, and most importantly 216 why this is so complex. 218 ISAKMP has the ability for an initiator to offer multiple protection 219 suites (a.k.a. proposals), with preferences associated to them. The 220 idea is that the peer has the ability to choose from one of the 221 proposals offerred. In addition it is possible for a proposal to 222 contain more than one transform for a given protocol (analogous to a 223 sub-proposal defined below) which the peer can use. 225 The following is an example of a complex, yet valid ISAKMP proposal: 227 +-- Protection Suite 1 --+ 228 | +-----+ | 229 | +---|SHA-1| | 230 | +----+ | +-----+ | 231 | +-| AH |--+ OR | 232 | | +----+ | +-----+ | 233 | | +---| MD5 | | 234 +-----|-+ AND +-----+ | 235 | | | | 236 | | | +----+ +-----+ | 237 | | +-| ESP|---| DES | | 238 | | +----+ +-----+ | 239 | +------------------------+ 240 +---+ OR 241 | 242 | +-- Protection Suite 2 --+ 243 | | +----+ +-----+ | 244 +-----|---| ESP|---| 3DES| | 245 | +----+ +-----+ | 246 +------------------------+ 248 In this scenario a requestor proposes two different protection suites, 249 one which consists of both AH and ESP, however note that the AH 250 proposal can use either SHA-1 OR MD5 (note that a preference would be 251 assigned to them). In addition ESP must be used with DES. 253 The requestor also proposes a second protection suite which only 254 consists of ESP using 3DES. 256 This type of complexity was not initially designed in the existing 257 DIAMETER protocol, since it is not necessary to correlate many 258 attributes to form a single "proposal". However, document [2] does 259 introduce this complexity with the use of the tag field. This document 260 will make use of this mechanism, but also requires additional 261 information within the DIAMETER attribute to include preference 262 information. 264 The new header format as described in section 5.0 is necessary in 265 order to be able to "build" policies as defined above. Such a policy 266 could be represented as follow: 268 Tag = 1 269 Protocol = AH / Preference = 1, 270 Transform = SHA-1, 271 Auth-Algorithm HMAC-SHA-1, 272 SA-Life-Seconds = 28800, 273 Encapsulation-Mode = Tunnel 274 Protocol = AH / Preference = 2, 275 Transform MD5, 276 Auth-Algorithm HMAC-MD5, 277 SA-Life-Kbs = 1024, 278 Encapsulation-Mode = Tunnel 279 Protocol = ESP / Preference = 1 280 Transform DES, 281 SA-Life-Seconds = 57600, 282 Encapsulation-Mode = Tunnel 284 Tag = 2 285 Protocol = ESP / Preference = 1 286 Transform = 3DES, 287 Auth-Algorithm DES-MAC, 288 SA-Life-Seconds = 57600, 289 SA-Life-Kbs = 2048, 290 Encapsulation-Mode = Tunnel 292 Tag = 3 293 Protocol = ESP / Preference = 1 294 Transform = 3DES, 295 Auth-Algorithm HMAC-SHA-1, 296 SA-Life-Seconds = 57600, 297 SA-Life-Kbs = 2048, 298 Encapsulation-Mode = Transport 300 The above defined policy states that Tag #1 has two AH transforms, the 301 preferred using SHA-1, the alternate using MD5. In addition ESP is to 302 be used with DES as the transform. The second proposal is to only use 303 ESP with 3DES as the transform. The third proposal is added for 304 completeness and depicts a simple policy using only ESP with 3DES in 305 transport mode. 307 Note that since both the Protocol and the Preference fields are used 308 to "classify" groups of attributes to form a single sub-proposal it is 309 not possible to have more than one protocol type with the same 310 preference number within a given tag. 312 4.0 Security Gateway Support 313 The IPSEC Architecture specification[9] defines the concept of a 314 security gateway, which is an intermediate node which provides some 315 security functions. This means that although security from the NAS to 316 the target host may be required, it also means that security from the 317 NAS to the intermediate node is also required. 319 This functionality further complicates this document since support for 320 such devices must be included. 322 Consider the following diagram which depicts such a configuration: 324 +-----+ 325 | | 326 +--| DIA | 327 +-----+ +-----+ | | | 328 | | PSTN | | | +-----+ 329 | Bill|------------| NAS |---| 330 | | | | | 331 +-----+ +-----+ | +-----+ +-----+ 332 | | | | | 333 +--| S G |----|Targ.| 334 | | | | 335 IP +-----+ +-----+ 337 In this scenario the NAS is informed that it must first establish an 338 ESP tunnel to the Security Gateway (SG), and then use AH in transport 339 mode to the target host shown above. 341 Due to this requirement, it must now be possible to associate the peer 342 with a given policy (as shown in section 3.0). Although it is possible 343 to create a new header format to support the above case it would be 344 preferable to simply use the format defined in section 5.0. 346 Using the header format defined in section 5.0 it is now possible to 347 define a security hierarchy as shown below: 349 Tag = 4 350 Protocol = First Host, 351 SA-Destination = SG, 352 Direction = Initiator, 353 Remote-ID = foo, 354 Policy = 1 / Preference = 1, 355 Policy = 2 / Preference = 2, 356 Next Hop = Target 358 Tag = 5 359 Protocol = NULL, 360 SA-Destination = Target, 361 SA-Direction = Initiator, 362 Remote-ID = bar, 363 Policy = 3 / Preference = 1 365 The above example describes that a secure link must be established 366 with the Security Gateway using either Policy 1 or 2 (with preference 367 given to #1). Once this is complete, a secure link must be established 368 with the target host using policy 3. Note that the Policy number is 369 essentially the tag number assigned to the policies described in 370 section 3.0 372 Given the mechanism described above it is now possible to build 373 complex hierarchies of security systems which must be penetrated in 374 order to reach the target host. Note that the last hop will not 375 necessarily be the target host since a Security Gateway may be 376 protecting the network instead. 378 Since Phase 2 security association are unidirectional, it is neccesary 379 to specify if the given policy is for the initiator or for the 380 responder. In the example given above, the "policies" are what the NAS 381 is to offer to the peer. When the SA-Direction is set to responder, it 382 informs the NAS what policies it may accept from the peer. 384 5.0 Attribute Format, Name and Code 386 This section will define the DIAMETER Attributes which are used to 387 send Security Policies or security hierarchies to the NAS for a given 388 user connection. 390 The new attribute format is shown below: 392 0 1 2 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 | Attribute Type | Length | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Flags | Vendor ID (opt) | Tag | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Protocol | Preference | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 Flag 404 This draft defines a new flag bit in the DIAMETER flag field: 406 4 - (T Bit) Indicates the presence of the Tag, Protocol and 407 Preference 408 fields. 410 Tag 412 The Tag field is one octet in length and is intended to provide a 413 means of grouping attributes in the same packet which refer to the 414 same policy or security hierarchy. 416 Protocol 418 A Protocol identifier. The following values are supported: 419 1 - Authentication Header (AH) 420 2 - Encapsulation Security Payload Header (ESP) 421 3 - Internet Securit Association Key Management Protocol 422 (ISAKMP) 423 4 - IP Compression (IPCOMP) 424 255 - First Host (First Host in a chain) 426 If the protocol identifier in the attributes is ISAKMP, the 427 resulting policy is meant for a Phase 1 exchange. A Phase 1 428 exchange creates ISAKMP SAs which protect further negotiation 429 traffic between the ISAKMP peers. 431 If the protocol identifier in the attribute is a protocol type 432 other than ISAKMP, the resulting policy is meant for use in a Phase 433 2 exchange. A Phase 2 exchange happens under the protection of a 434 pre-existing Phase 1 SA, and negotiates a SA for the protocol 435 specified in the attribute. 437 Preference 439 The specific preference for the stated protocol. 441 Attribute Name: Transform 442 Attribute Code: 278 444 Attribute Name: Encryption-Algorithm 445 Attribute Code: 279 447 Attribute Name: Hash-Algorithm 448 Attribute Code: 280 450 Attribute Name: Authentication-Mechanism 451 Attribute Code: 281 453 Attribute Name: SA-Life-Seconds 454 Attribute Code: 282 456 Attribute Name: SA-Life-Kbs 457 Attribute Code: 283 459 Attribute Name: DH-Group 460 Attribute Code: 284 462 Attribute Name: Key-Length 463 Attribute Code: 285 465 Attribute Name: Key-Round 466 Attribute Code: 286 468 Attribute Name: Encapsulation-Mode 469 Attribute Code: 287 471 Attribute Name: Initiator-Id 472 Attribute Code: 288 474 Attribute Name: Responder-Id 475 Attribute Code: 289 477 Attribute Name: SA-Destination 478 Attribute Code: 290 480 Attribute Name: Policy 481 Attribute Code: 291 483 Attribute Name: Next-Hop 484 Attribute Code: 292 486 Attribute Name: SA-Direction 487 Attribute Code: 293 489 Attribute Name: Anti-Replay 490 Attribute Code: 294 492 6.0 Attribute Meanings 494 6.1 Transform 496 This attributes states the desired transform for the protocol. 498 0 1 2 3 499 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 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Attribute Type | Length | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Flags | Tag | Protocol | Preference | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Value | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Attribute Type 510 278 for Transform 512 Length 514 12 516 Tag 518 The Tag field is one octet in length and is intended to provide a 519 means of grouping attributes in the same packet which refer to the 520 same policy. This value is also used as a policy identifier. 522 Protocol 524 The Protocol field identifies for which protocol this attribute is 525 to be used with as defined previously. 527 Flag 529 The Flag field has no meaning with this attribute. 531 Preference 533 The Preference field identifies the preference of the current 534 transform within the proposal. The policy with the lowest 535 preference value is prefered. 537 Value 539 The value field contains the transform ID. Note that this field is 540 used in conjunction with the protocol ID in order to identify the 541 specific transform. The following values are supported: 542 0 - NULL (ESP Only) 543 1 - DES (ESP and AH) 544 2 - 3DES (ESP Only) 545 3 - DES_IV64 (ESP Only) 546 4 - RC5 (ESP Only) 547 5 - IDEA (ESP Only) 548 6 - CAST (ESP Only) 549 7 - Blowfish (ESP Only) 550 8 - 3IDEA (ESP Only) 551 9 - DES_IV32 (ESP Only) 552 10 - ARCFOUR (ESP Only) 553 11 - MD5 (AH Only) 554 12 - SHA-1 (AH Only) 555 13 - Oakley (ISAKMP Only) 556 14 - LZS (IPCOMP Only) 557 15 - V.42bis (IPCOMP Only) 558 16 - DEFLATE (IPCOMP Only) 560 It is considered invalid to specify a value which is not relevant 561 to the stated protocol ID in the attribute header. 563 6.2 Encryption-Algorithm 565 This attribute states the desired encryption algorithm for ISAKMP 566 phase 1 exchange. 568 0 1 2 3 569 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 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Attribute Type | Length | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Flags | Tag | Protocol | Preference | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Value | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 Attribute Type 580 279 for Encryption-Algorithm 582 Length 584 12 586 Tag 588 The Tag field is one octet in length and is intended to provide a 589 means of grouping attributes in the same packet which refer to the 590 same policy. This value is also used as a policy identifier. 592 Protocol 593 The Protocol field MUST be set to ISAKMP. 595 Flag 597 The Flag field has no meaning with this attribute. 599 Preference 601 The Preference field identifies the preference of the current 602 policy. The policy with the lowest preference value is prefered. 604 Value 606 The value field contains the transform ID. Note that this field is 607 used in conjunction with the protocol ID in order to identify the 608 specific transform. The following values are supported: 609 1 - DES-CBC 610 2 - IDEA-CBC 611 3 - Blowfish-CBC 612 4 - RC5-R16-B64-CBC 613 5 - 3DES-CBC 614 6 - CAST-CBC 616 6.3 Hash-Algorithm 618 This attribute states the desired hash algorithm for ISAKMP phase 1 619 exchange. 621 0 1 2 3 622 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 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | Attribute Type | Length | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Flags | Tag | Protocol | Preference | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Value | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 Attribute Type 633 280 for Hash-Algorithm 635 Length 636 12 638 Tag 640 The Tag field is one octet in length and is intended to provide a 641 means of grouping attributes in the same packet which refer to the 642 same policy. This value is also used as a policy identifier. 644 Protocol 646 The Protocol field MUST be set to ISAKMP. 648 Flag 650 The Flag field has no meaning with this attribute. 652 Preference 654 The Preference field identifies the preference of the current 655 policy. The policy with the lowest preference value is prefered. 657 Value 659 The value field contains the transform ID. Note that this field is 660 used in conjunction with the protocol ID in order to identify the 661 specific transform. The following values are supported: 662 1 - MD5 663 2 - SHA 664 3 - Tiger 666 6.4 Authentication-Method 668 This attributes states the desired authentication algorithm for the 669 IPSEC protocols. 671 0 1 2 3 672 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 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Attribute Type | Length | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | Flags | Tag | Protocol | Preference | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Value | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 Attribute Type 683 281 for Authentication-Method 685 Length 687 12 689 Tag 691 The Tag field is one octet in length and is intended to provide a 692 means of grouping attributes in the same packet which refer to the 693 same policy. This value is also used as a policy identifier. 695 Protocol 697 The Protocol field identifies for which protocol this attribute is 698 to be used with as defined previously. 700 Flag 702 The Flag field has no meaning with this attribute. 704 Preference 706 The Preference field identifies the preference of the current 707 policy. The policy with the lowest preference value is prefered. 709 Value 711 The value field contains the transform ID. Note that this field is 712 used in conjunction with the protocol ID in order to identify the 713 specific transform. The following values are supported: 714 1 - HMAC-MD5 (ESP and AH) 715 2 - HMAC-SHA-1 (ESP and AH) 716 3 - DES-MAC (ESP and AH) 717 4 - Pre-Shared key (ISAKMP Only) 718 5 - DSS-Signature (ISAKMP Only) 719 6 - RSA-Signature (ISAKMP Only) 720 7 - RSA-Encryption (ISAKMP Only) 721 8 - Revised-RSA-Encryption (ISAKMP Only) 722 9 - GSSAPI-Authentication (ISAKMP Only) 723 10 - KPDK (AH Only - MUST be used with MD5 as transform only) 725 It is considered invalid to specify a value which is not relevant 726 to the stated protocol ID in the attribute header. 728 6.5 SA-Life-Seconds 730 This attributes states the lifetime for the generated Security 731 Association for the IPSEC protocol requested. This attribute defines 732 the lifetime in the number of seconds once the SA is established. 734 0 1 2 3 735 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 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Attribute Type | Length | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Flags | Tag | Protocol | Preference | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Value | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 Attribute Type 746 282 for SA-Life-Seconds 748 Length 750 12 752 Tag 754 The Tag field is one octet in length and is intended to provide a 755 means of grouping attributes in the same packet which refer to the 756 same policy. This value is also used as a policy identifier. 758 Protocol 760 The Protocol field identifies for which protocol this attribute is 761 to be used with as defined previously. 763 Flag 765 The Flag field has no meaning with this attribute. 767 Preference 768 The Preference field identifies the preference of the current 769 policy. The policy with the lowest preference value is prefered. 771 Value 773 The value field contains the number of seconds before the Security 774 Association must be renegotiated. 776 6.6 SA-Life-Kbs 778 This attributes states the lifetime for the generated Security 779 Association for the IPSEC protocol requested. This attribute defines 780 the lifetime in the number of kilobytes transmitted once the SA is 781 established. 783 0 1 2 3 784 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 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | Attribute Type | Length | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | Flags | Tag | Protocol | Preference | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Value | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 Attribute Type 795 283 for SA-Life-Kbs 797 Length 799 12 801 Tag 803 The Tag field is one octet in length and is intended to provide a 804 means of grouping attributes in the same packet which refer to the 805 same policy. This value is also used as a policy identifier. 807 Protocol 809 The Protocol field identifies for which protocol this attribute is 810 to be used with as defined previously. 812 Flag 814 The Flag field has no meaning with this attribute. 816 Preference 818 The Preference field identifies the preference of the current 819 policy. The policy with the lowest preference value is prefered. 821 Value 823 The value field contains the number of kilobytes before the 824 Security Association must be renegotiated. 826 6.7 DH-Group 828 This attribute is used to indicate the Diffie-Hellman group for the 829 phase 2 exchange. If perfect forward secrecy is desired, this 830 attribute must be included. It allows for the negotiation of a fresh 831 DH key for phase 2. This new ephemeral DH key can then be used 832 instead of the phase 1 DH key, to derive session keys for the 833 negotiated transforms. 835 The attribute's format is as follows: 837 0 1 2 3 838 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 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | Attribute Type | Length | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | Flags | Tag | Protocol | Preference | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Value | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 Attribute Type 849 284 for DH-Group 851 Length 853 12 855 Tag 856 The Tag field is one octet in length and is intended to provide a 857 means of grouping attributes in the same packet which refer to the 858 same policy. This value is also used as a policy identifier. 860 Protocol 862 The Protocol field identifies for which protocol this attribute is 863 to be used with as defined previously. This attribute is not valid 864 for IPCOMP. 866 Flag 868 The Flag field has no meaning with this attribute. 870 Preference 872 The Preference field identifies the preference of the current 873 policy. The policy with the lowest preference value is prefered. 875 Value 877 The value field contains the Diffie-Hellman group and may have one 878 of the following values: 879 1 - First-Oakley-Group (MODP 768 bit) 880 2 - Second-Oakley-Group (MODP 1024 bit) 881 3 - Third-Oakley-Group (EC2N on GP[2^155]) 882 4 - Fourth-Oakley-Group (EC2N on GP[2^185]) 884 6.8 Key-Length 886 For transforms that take variable length keys, this attribute can be 887 used to indicate the key length desired. Its format is as follows: 889 0 1 2 3 890 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 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | Attribute Type | Length | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | Flags | Tag | Protocol | Preference | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | Value | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 Attribute Type 900 285 for Key-Length 902 Length 904 12 906 Tag 908 The Tag field is one octet in length and is intended to provide a 909 means of grouping attributes in the same packet which refer to the 910 same policy. This value is also used as a policy identifier. 912 Protocol 914 The Protocol field identifies for which protocol this attribute is 915 to be used with as defined previously. This attribute is not valid 916 for IPCOMP. 918 Flag 920 The Flag field has no meaning with this attribute. 922 Preference 924 The Preference field identifies the preference of the current 925 policy. The policy with the lowest preference value is prefered. 927 Value 929 This field contains a non-zero length for the key. 931 6.9 Key-Round 933 For transforms that have varying number of rounds, this attribute can 934 be used to indicate the desired number of rounds. Its format is as 935 follows: 937 0 1 2 3 938 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 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Attribute Type | Length | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Flags | Tag | Protocol | Preference | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | Value | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 Attribute Type 949 286 for Key-Rounds 951 Length 953 12 955 Tag 957 The Tag field is one octet in length and is intended to provide a 958 means of grouping attributes in the same packet which refer to the 959 same policy. This value is also used as a policy identifier. 961 Protocol 963 The Protocol field identifies for which protocol this attribute is 964 to be used with as defined previously. This attribute is not valid 965 for IPCOMP. 967 Flag 969 The Flag field has no meaning with this attribute. 971 Preference 973 The Preference field identifies the preference of the current 974 policy. The policy with the lowest preference value is prefered. 976 Value 978 This field contains a non-zero key round value. 980 6.10 Encapsulation-Mode 982 This attribute indicates the encapsulation mode for the given 983 protocol. The attribute's format is as follows: 985 0 1 2 3 986 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 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | Attribute Type | Length | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | Flags | Tag | Protocol | Preference | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | Value | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 Attribute Type 997 287 for Encapsulation-Mode 999 Length 1001 12 1003 Tag 1005 The Tag field is one octet in length and is intended to provide a 1006 means of grouping attributes in the same packet which refer to the 1007 same policy. This value is also used as a policy identifier. 1009 Protocol 1011 The Protocol field identifies for which protocol this attribute is 1012 to be used with as defined previously. 1014 Flag 1016 The Flag field has no meaning with this attribute. 1018 Preference 1020 The Preference field identifies the preference of the current 1021 policy. The policy with the lowest preference value is prefered. 1023 Value 1025 The value field may have one of the following values: 1026 1 - Tunnel-Mode 1027 2 - Transport-Mode 1029 6.11 Initiator-Id 1031 This attribute is used to indicate the identity of the ISAKMP exchange 1032 initiator. 1034 If the protocol field is ISAKMP, the identity is meant for a Phase 1 1035 exchange (IDii in [4]). If the NAS happens to be the initiator, it 1036 knows its local identity. In this case, the attribute SHOULD not be 1037 sent in the Access-Accept. However, if the attribute is sent in the 1038 Access-Accept, the NAS has an option of ignoring it. If the attribute 1039 is not present in the Access-Accept, the NAS MUST assume that it is to 1040 provide its own identity. 1042 If the protocol field is anything but ISAKMP, the attribute provides 1043 the user identity on the initiator side for a Phase 2 exchange (IDui 1044 in [4]). 1046 0 1 2 3 1047 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 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | Attribute Type | Length | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | Flags | Tag | Protocol | Preference | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | ID Type | String... | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 Attribute Type 1058 288 for Initiator-Id 1060 Length 1062 >10 1064 Tag 1066 The Tag field is one octet in length and is intended to provide a 1067 means of grouping attributes in the same packet which refer to the 1068 same policy. This value is also used as a policy identifier. 1070 Protocol 1072 The Protocol field identifies for which protocol this attribute is 1073 to be used with as defined previously. This attribute is not valid 1074 for ISAKMP. 1076 Flag 1078 The Flag field has no meaning with this attribute. 1080 Preference 1082 The Preference field identifies the preference of the current 1083 policy. The policy with the lowest preference value is prefered. 1085 ID Type 1087 The ID Type field is one octet in length and represents the format 1088 of the address. The following values are supported: 1089 1 - IPV4-Address (4 octets) 1090 2 - IPV6-Address (20 octets) 1091 3 - FQ-Domain-Name (e.g. 3com.com) 1092 4 - FQ-User-Name (e.g. lobo@3com.com) 1093 5 - IPV4-Subnet (4 octets address followed by 4 octets 1094 subnet mask) 1095 6 - IPV4-Range (4 octets start address followed by 1096 by a 4 octet end address) 1097 7 - X.500-Distinguished-Name 1098 8 - X.500-General-Name 1099 9 - Vendor-Specific (pre-shared key identity) 1101 String 1103 The string field contains the local identifier. 1105 6.12 Responder-Id 1107 This attribute is used to indicate the identity of the ISAKMP exchange 1108 responder. 1110 If the protocol field is ISAKMP, the identity is meant for a Phase 1 1111 exchange (IDir in [4]). If the NAS happens to be the responder, it 1112 knows its local identity. In this case, the attribute SHOULD not be 1113 sent in the Access-Accept. However, if the attribute is sent in the 1114 Access-Accept, the NAS has an option of ignoring it. If the attribute 1115 is not present in the Access-Accept, the NAS MUST assume that it is to 1116 provide its own identity. 1118 If the protocol field is anything but ISAKMP, the attribute provides 1119 the user identity on the responder side for a Phase 2 exchange (IDur 1120 in [4]). 1122 0 1 2 3 1123 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 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 | Attribute Type | Length | 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 | Flags | Tag | Protocol | Preference | 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 | ID Type | String... | 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 Attribute Type 1134 289 for Remote-Id 1136 Length 1138 >10 1140 Tag 1142 The Tag field is one octet in length and is intended to provide a 1143 means of grouping attributes in the same packet which refer to the 1144 same Security Association Endpoint. 1146 Protocol 1148 The Protocol field identifies for which protocol this attribute is 1149 to be used with as defined previously. 1151 Flag 1153 The Flag field has no meaning with this attribute. 1155 Preference 1157 The Preference field identifies the preference of the current 1158 policy. The policy with the lowest preference value is prefered. 1160 ID Type 1162 The ID Type field is one octet in length and represents the format 1163 of the address. The following values are supported: 1164 1 - IPV4-Address (4 octets) 1165 2 - IPV6-Address (20 octets) 1166 3 - FQ-Domain-Name (e.g. 3com.com) 1167 4 - FQ-User-Name (e.g. lobo@3com.com) 1168 5 - IPV4-Subnet (4 octets address followed by 4 octets 1169 subnet mask) 1170 6 - IPV4-Range (4 octets start address followed by 1171 by a 4 octet end address) 1172 7 - X.500-Distinguished-Name 1173 8 - X.500-General-Name 1174 9 - Vendor-Specific (pre-shared key identity) 1176 Value 1178 The value field contains the remote identifier. 1180 6.13 SA-Destination 1182 This attributes defines the destination address with which the 1183 Security Association will be established. 1185 0 1 2 3 1186 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 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 | Attribute Type | Length | 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | Flags | Tag | Protocol | Preference | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | Value | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 Attribute Type 1197 290 for SA-Destination 1199 Length 1201 12 1203 Tag 1205 The Tag field is one octet in length and is intended to provide a 1206 means of grouping attributes in the same packet which refer to the 1207 same Security Association Endpoint. 1209 Protocol 1211 The Protocol field has no meaning for this attribute. 1213 Flag 1215 The Flag field is used in order to identify the first host in a 1216 chain of Security Associations. The S bit is enabled if this host 1217 is the first security hop to the target. Note that this bit MUST be 1218 enabled even if the first hop is also the last hop. 1220 Preference 1222 The Preference field has no meaning for this attribute. 1224 Value 1226 The value field contains the address of the IPSEC destination, 1227 which may be the target host or an intervening Security Gateway. 1229 6.14 Policy 1231 This attribute is used to reference a specific policy for the user. 1232 When more than a single instance of this attribute is present within a 1233 given tag, the preference field is used in order to identify the 1234 prefered policy. 1236 0 1 2 3 1237 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 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1239 | Attribute Type | Length | 1240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 | Flags | Tag | Protocol | Preference | 1242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1243 | Value | 1244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 Attribute Type 1248 291 for Policy 1250 Length 1252 12 1254 Tag 1256 The Tag field is one octet in length and is intended to provide a 1257 means of grouping attributes in the same packet which refer to the 1258 same Security Association Endpoint. 1260 Protocol 1262 The Protocol field has no meaning for this attribute. 1264 Flag 1266 The Flag field has no meaning with this attribute. 1268 Preference 1270 The Preference field identifies the preference of the stated 1271 policy. The policy with the lowest preference value is prefered. 1273 Value 1275 The Value field contains the policy identifier as described above. 1276 When used with the Preference field it is used in order to 1277 associate preferred policies to use for a given SA-Destination. 1279 6.15 Next-Hop 1281 This attribute is used in order to identify the next hop in a chain of 1282 security associations. This attribute is used when it is necessary to 1283 establish a secure link with a security gateway in order to reach a 1284 host using IPSEC or in the case of multiple security gateways. 1286 0 1 2 3 1287 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 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 | Attribute Type | Length | 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 | Flags | Tag | Protocol | Preference | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 | Value | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 Attribute Type 1297 292 for Next-Hop 1299 Length 1301 12 1303 Tag 1305 The Tag field is one octet in length and is intended to provide a 1306 means of grouping attributes in the same packet which refer to the 1307 same Security Association Endpoint. 1309 Protocol 1311 The Protocol field has no meaning for this attribute. 1313 Flag 1315 The Flag field has no meaning with this attribute. 1317 Preference 1319 The Preference field has no meaning with this attribute. 1321 Value 1323 The value field contains the address of the next hop. 1325 6.16 SA-Direction 1327 A Phase 2 SA is unidirectional. This means that a pair of SAs are 1328 required to secure a session. If the NAS is initiating the Phase 2 SA 1329 exchange, it needs a set of protection suites that it can propose to 1330 its peer. 1332 On the other hand, if the NAS is responding to a Phase 2 SA exchange, 1333 it receives a set of protection suites from its peer. In this case, it 1334 needs a set of local protection suites to compare the proposed suites 1335 against. Hence it becomes necessary to provide the NAS with two sets 1336 of protection suites; one for use when it is the initiator, and the 1337 other when it is the responder. 1339 0 1 2 3 1340 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 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 | Attribute Type | Length | 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 | Flags | Tag | Protocol | Preference | 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 | Value | 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1349 Attribute Type 1351 293 for SA-Direction 1353 Length 1355 12 1357 Tag 1359 The Tag field is one octet in length and is intended to provide a 1360 means of grouping attributes in the same packet which refer to the 1361 same Security Association Endpoint. 1363 Protocol 1365 The Protocol field has no meaning for this attribute. 1367 Flag 1369 The Flag field has no meaning with this attribute. 1371 Preference 1373 The Preference field has no meaning with this attribute. 1375 Value 1377 The value field contains the direction of the Security Association. 1378 The following values are supported: 1379 1 - Initiator 1380 2 - Reponder 1382 6.17 Anti-Replay 1384 The Anti-Replay attribute is used in order to identify whether anti- 1385 replay is to be used for the policy. 1387 0 1 2 3 1388 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 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 | Attribute Type | Length | 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 | Flags | Tag | Protocol | Preference | 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 | Value | 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1397 Attribute Type 1399 294 for Anti-Replay 1401 Length 1403 12 1405 Tag 1407 The Tag field is one octet in length and is intended to provide a 1408 means of grouping attributes in the same packet which refer to the 1409 same policy. This value is also used as a policy identifier. 1411 Protocol 1413 The Protocol field identifies for which protocol this attribute is 1414 to be used with as defined previously. This attribute is only valid 1415 for ESP. 1417 Flag 1419 The Flag field has no meaning with this attribute. 1421 Preference 1423 The Preference field identifies the preference of the current 1424 policy. The policy with the lowest preference value is prefered. 1426 Value 1428 The value field may have one of the following values: 1429 1 - Anti-Replay-Enabled 1430 2 - Anti-Replay-Disabled 1432 6.18 Table of Attributes 1434 The following table provides a guide to which of the above 1435 attributes may be found in which kinds of packets, and in what 1436 quantity. 1438 Authentication- Attribute 1439 Request Success Reject Number Name 1440 0 0+ 0 278 Transform 1441 0 0+ 0 279 Encryption-Algorithm 1442 0 0+ 0 280 Hash-Algorithm 1443 0 0+ 0 281 Authentication-Mechanism 1444 0 0+ 0 282 SA-Life-Seconds 1445 0 0+ 0 283 SA-Life-Kbs 1446 0 0+ 0 284 DH-Group 1447 0 0+ 0 285 Key-Length 1448 0 0+ 0 286 Key-Round 1449 0 0+ 0 287 Encapsulation-Mode 1450 0 0+ 0 288 Initiator-Id 1451 0 0+ 0 289 Responder-Id 1452 0 0+ 0 290 SA-Destination 1453 0 0+ 0 291 Policy 1454 0 0+ 0 292 Next-Hop 1455 0 0+ 0 293 SA-Direction 1456 0 0+ 0 294 Anti-Replay 1458 The following table defines the meaning of the above table entries. 1460 0 This attribute MUST NOT be present in packet. 1461 0+ Zero or more instances of this attribute MAY be present in 1462 packet. 1463 0-1 Zero or one instance of this attribute MAY be present in 1464 packet. 1466 7.0 References 1468 [1] P. R. Calhoun, A. Rubens, "DIAMETER Base Protocol", 1469 draft-calhoun-diameter-00.txt, February 1998. 1471 [2] C. Zorn, D. Leifer, John Shriver, "RADIUS Attributes for 1472 Tunnel Protocol Support", Internet Draft, July 1997. 1474 [3] K. Hamzeh, T. Kolar, M. Littlewood, G. Singh Pall, J. Taarud, 1475 A. J. Valencia, W. Verthein, W.M. Townsley, B. Palter, 1476 A. Rubens "Layer Two Tunneling Protocol (L2TP)", 1478 [4] D. Harkins D., D. Carrel, "The Resolution of ISAKMP with 1479 Oakley", Internet Draft, July 1997 1481 [5] D. Maughan, M. Schertler, M. Schneider, J. Turner, 1482 "Internet Security Association and Key Management Protocol 1483 (ISAKMP)", Internet Draft, July 1997 1485 [6] D. Piper, "The Internet IP Security Domain Of Interpretation 1486 for ISAKMP",Internet Draft, October 1997 1488 [7] S. Kent, R. Atkinson, "IP Encapsulating Security Payload", 1490 [8] S. Kent, R. Atkinson, "IP Authentication Header", 1492 [9] R. Atkinson, "Security Architecture for the Internet Protocol", 1493 RFC 1825, August 1995 1495 [10] J. Reynolds, J. Postel, "Assigned Numbers", STD 2, RFC 1700, 1496 USC/Information Sciences Institute, October 1994 1498 [11] P. R. Calhoun, "DIAMETER Authentication Extension", 1499 draft-calhoun-diameter-auth-00.txt, February 1998. 1501 8.0 Author's Address 1503 Questions about this memo can also be directed to: 1505 Sumit A. Vakil 1506 3Com Corporation 1507 1800 W. Central Rd. 1508 Mount Prospect, Il, 60056 1509 USA 1511 Phone: 1-847-342-6892 1512 Fax: 1-847-222-2424 1513 E-mail: Sumit_Vakil@MW.3Com.Com 1515 Pat R. Calhoun 1516 Technology Development 1517 Sun Microsystems, Inc. 1518 15 Network Circle 1519 Menlo Park, California, 94025 1520 USA 1522 Phone: 1-847-548-9587 1523 Fax: 1-650-786-6445 1524 E-mail: pcalhoun@toast.net