INTERNET DRAFT Sumit A. Vakil Category: Standards Track 3Com Corporation Title: draft-calhoun-diameter-ipsec-policy-00.txt Pat R. Calhoun Date: March 1998 Sun Microsystems, Inc. DIAMETER IP Security Policy Extensions Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. Abstract The DIAMETER User Authentication/Authorization extension defines a mechanism which is used by a Network Access Server (NAS) to authenticate dial-up users. IP Security defines a mechanism of establishing a secure link between two entities over a network. This document defines a mechanism for DIAMETER to inform the NAS of the security policies required for secure communication with a host. Table of Contents 1.0 Introduction 1.1 Conventions 2.0 Operation 2.1 Login User 2.2 Tunneled User 3.0 Policy Building 4.0 Security Gateway Support Vakil, Calhoun expires September 1998 [Page 1] INTERNET DRAFT March 1998 5.0 Attribute Format, Name and Code 6.0 RADIUS Attributes 6.1 Transform 6.2 Encryption-Algorithm 6.3 Authentication-Algorithm 6.4 Authentication-Method 6.5 SA-Life-Seconds 6.6 SA-Life-Kbs 6.7 DH-Group 6.8 Key-Length 6.9 Key-Round 6.10 Enapsulation-Mode 6.11 Local-Id 6.12 Remote-Id 6.13 SA-Destination 6.14 Policy 6.15 Next-Hop 6.16 SA-Direction 6.17 Anti-Replay 6.18 Table of Attributes 7.0 References 8.0 Author's Address 1.0 Introduction DIAMETER is a proposed protocol for dial-up user authentication, authorization and accounting. In the case of "login" or tunneled users, where the NAS initiates a connection to a specified host on behalf of the user [1][2], the authorization information returned in the DIAMETER message contains the target host information. The only current security mechanism used to secure the connection is to rely on the source IP address of the target host (which is very weak security). The IP Security (IPSEC) protocol suite is used by entities in order to communicate in a secure fashion over an untrusted network. In order for the NAS to be able to establish a secure link with a destination host or network it requires a set of security policies which defines the target as well as the different transforms which are to be used during the communication. These policies need to be pre-configured on the NAS prior to establishing the secure link. Since an ISPs users will connect to a variety of hosts over the internet, it becomes very difficult to statically configure these policies for every possible host which a dial-up user may need to connect to. In the case of tunneling, where customers are outsourcing their dial-up services to a service provider this becomes even more complex. It would therefore be desirable to have this information maintained by an AAA server. Vakil, Calhoun expires September 1998 [Page 2] INTERNET DRAFT March 1998 The fact that ROAMOPS is creating standards to allow users to roam to any service provider to get internet access complicates the problem even further. It is clear in this scenario that the AAA protocol MUST be able to download IPSEC Security Policies to a NAS. 1.1 Conventions The following language conventions are used in the items of specifi- cation in this document: o MUST, SHALL, or MANDATORY -- This item is an absolute requirement of the specification. o SHOULD or RECOMMEND -- This item should generally be followed for all but exceptional circumstances. o MAY or OPTIONAL -- This item is truly optional and may be followed or ignored according to the needs of the implementor. Vakil, Calhoun expires September 1998 [Page 3] INTERNET DRAFT March 1998 2.0 Operation In this section we will examine two possible types of users. In the first example we will describe a login user, and the second will define how a tunneled user would use the extensions used in this document. 2.1 Login User In this section we will look an at example of a login user. The user, named joe, dials into a NAS which authenticates the user with the assistance of a local DIAMETER Server. The user's DIAMETER profile is shown below: joe Password = password Service-Type = Login, Login-Service = Telnet, Login-IP-Host = 10.1.1.1, Login-Port = 23 As the user's profile depicts, once the user is authenticated the NAS will create a telnet session to target host 10.1.1.1 on behalf of the user. In this case the NAS is used as a terminal server and sends all of the user's asynchronous data to the target encapsulated within a telnet session. +-----+ | | +--| DIA | +-----+ +-----+ | | | | | PSTN | | | +-----+ | Joe |------------| NAS |---| | | | | | +-----+ +-----+ | +-----+ | | | +--|Targ.| | | IP +-----+ As stated above IPSEC is a mechanism used by the NAS and the target to establish a secure telnet connection for the user. Traditionally the NAS must have security policies defined locally which state that all communication with the target host for the user must be secured, and more importantly how secure the communication must be. 2.2 Tunneled User Document [3] defines a protocol which is used by a NAS to "tunnel" all Vakil, Calhoun expires September 1998 [Page 4] INTERNET DRAFT March 1998 PPP data from the user to a destination host. This encapsulation is done in order to allow a user to connect to a destination network from the internet as well as to allow multi-protocol over an IP network. Document [2] defines RADIUS attributes which may be sent from the DIAMETER Server to the NAS which contain tunneling information, such as the target tunnel endpoint. In this example we will examine a user named bill which dials into a NAS which authenticates the user using a local DIAMETER Server. The DIAMETER Server informs the NAS that tunneling must occur for the user as shown in the user's profile below. bill Password = password Service-Type = Framed, Framed-Protocol = PPP, Framed-IP-Netmask = 255.255.255.255, Framed-MTU = 1500, Framed-IP-Address = 2.3.4.5 , Tunnel-Type = L2TP, Tunnel-Medium-Type = IP, Tunnel-Server-Endpoint = 10.1.1.2, Tunnel-Password = password As the user's profile states, once the user is authenticated the NAS will create an L2TP tunnel with the target tunnel endpoint 10.1.1.2. Once the tunnel is established all PPP traffic will be encapsulated and forwarded to the target. +-----+ | | +--| DIA | +-----+ +-----+ | | | | | PSTN | | | +-----+ | Bill|------------| NAS |---| | | | | | +-----+ +-----+ | +-----+ | | | +--|Targ.| | | IP +-----+ As stated above IPSEC is a mechanism used by the NAS and the target to establish a secure tunnel for the user. Traditionally the NAS must have security policies defined locally which state that all communication with the target host for the user must be secured, and more importantly how secure the communication must be. 3.0 Policy Building Vakil, Calhoun expires September 1998 [Page 5] INTERNET DRAFT March 1998 This section will define how Policies are built, and most importantly why this is so complex. ISAKMP has the ability for an initiator to offer multiple protection suites (a.k.a. proposals), with preferences associated to them. The idea is that the peer has the ability to choose from one of the proposals offerred. In addition it is possible for a proposal to contain more than one transform for a given protocol (analogous to a sub-proposal defined below) which the peer can use. The following is an example of a complex, yet valid ISAKMP proposal: +-- Protection Suite 1 --+ | +-----+ | | +---|SHA-1| | | +----+ | +-----+ | | +-| AH |--+ OR | | | +----+ | +-----+ | | | +---| MD5 | | +-----|-+ AND +-----+ | | | | | | | | +----+ +-----+ | | | +-| ESP|---| DES | | | | +----+ +-----+ | | +------------------------+ +---+ OR | | +-- Protection Suite 2 --+ | | +----+ +-----+ | +-----|---| ESP|---| 3DES| | | +----+ +-----+ | +------------------------+ In this scenario a requestor proposes two different protection suites, one which consists of both AH and ESP, however note that the AH proposal can use either SHA-1 OR MD5 (note that a preference would be assigned to them). In addition ESP must be used with DES. The requestor also proposes a second protection suite which only consists of ESP using 3DES. This type of complexity was not initially designed in the existing DIAMETER protocol, since it is not necessary to correlate many attributes to form a single "proposal". However, document [2] does introduce this complexity with the use of the tag field. This document will make use of this mechanism, but also requires additional information within the DIAMETER attribute to include preference information. Vakil, Calhoun expires September 1998 [Page 6] INTERNET DRAFT March 1998 The new header format as described in section 5.0 is necessary in order to be able to "build" policies as defined above. Such a policy could be represented as follow: Tag = 1 Protocol = AH / Preference = 1, Transform = SHA-1, Auth-Algorithm HMAC-SHA-1, SA-Life-Seconds = 28800, Encapsulation-Mode = Tunnel Protocol = AH / Preference = 2, Transform MD5, Auth-Algorithm HMAC-MD5, SA-Life-Kbs = 1024, Encapsulation-Mode = Tunnel Protocol = ESP / Preference = 1 Transform DES, SA-Life-Seconds = 57600, Encapsulation-Mode = Tunnel Tag = 2 Protocol = ESP / Preference = 1 Transform = 3DES, Auth-Algorithm DES-MAC, SA-Life-Seconds = 57600, SA-Life-Kbs = 2048, Encapsulation-Mode = Tunnel Tag = 3 Protocol = ESP / Preference = 1 Transform = 3DES, Auth-Algorithm HMAC-SHA-1, SA-Life-Seconds = 57600, SA-Life-Kbs = 2048, Encapsulation-Mode = Transport The above defined policy states that Tag #1 has two AH transforms, the preferred using SHA-1, the alternate using MD5. In addition ESP is to be used with DES as the transform. The second proposal is to only use ESP with 3DES as the transform. The third proposal is added for completeness and depicts a simple policy using only ESP with 3DES in transport mode. Note that since both the Protocol and the Preference fields are used to "classify" groups of attributes to form a single sub-proposal it is not possible to have more than one protocol type with the same preference number within a given tag. 4.0 Security Gateway Support Vakil, Calhoun expires September 1998 [Page 7] INTERNET DRAFT March 1998 The IPSEC Architecture specification[9] defines the concept of a security gateway, which is an intermediate node which provides some security functions. This means that although security from the NAS to the target host may be required, it also means that security from the NAS to the intermediate node is also required. This functionality further complicates this document since support for such devices must be included. Consider the following diagram which depicts such a configuration: +-----+ | | +--| DIA | +-----+ +-----+ | | | | | PSTN | | | +-----+ | Bill|------------| NAS |---| | | | | | +-----+ +-----+ | +-----+ +-----+ | | | | | +--| S G |----|Targ.| | | | | IP +-----+ +-----+ In this scenario the NAS is informed that it must first establish an ESP tunnel to the Security Gateway (SG), and then use AH in transport mode to the target host shown above. Due to this requirement, it must now be possible to associate the peer with a given policy (as shown in section 3.0). Although it is possible to create a new header format to support the above case it would be preferable to simply use the format defined in section 5.0. Using the header format defined in section 5.0 it is now possible to define a security hierarchy as shown below: Tag = 4 Protocol = First Host, SA-Destination = SG, Direction = Initiator, Remote-ID = foo, Policy = 1 / Preference = 1, Policy = 2 / Preference = 2, Next Hop = Target Tag = 5 Protocol = NULL, SA-Destination = Target, SA-Direction = Initiator, Remote-ID = bar, Vakil, Calhoun expires September 1998 [Page 8] INTERNET DRAFT March 1998 Policy = 3 / Preference = 1 The above example describes that a secure link must be established with the Security Gateway using either Policy 1 or 2 (with preference given to #1). Once this is complete, a secure link must be established with the target host using policy 3. Note that the Policy number is essentially the tag number assigned to the policies described in section 3.0 Given the mechanism described above it is now possible to build complex hierarchies of security systems which must be penetrated in order to reach the target host. Note that the last hop will not necessarily be the target host since a Security Gateway may be protecting the network instead. Since Phase 2 security association are unidirectional, it is neccesary to specify if the given policy is for the initiator or for the responder. In the example given above, the "policies" are what the NAS is to offer to the peer. When the SA-Direction is set to responder, it informs the NAS what policies it may accept from the peer. 5.0 Attribute Format, Name and Code This section will define the DIAMETER Attributes which are used to send Security Policies or security hierarchies to the NAS for a given user connection. The new attribute format is shown below: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Vendor ID (opt) | Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flag This draft defines a new flag bit in the DIAMETER flag field: 4 - (T Bit) Indicates the presence of the Tag, Protocol and Preference fields. Vakil, Calhoun expires September 1998 [Page 9] INTERNET DRAFT March 1998 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same policy or security hierarchy. Protocol A Protocol identifier. The following values are supported: 1 - Authentication Header (AH) 2 - Encapsulation Security Payload Header (ESP) 3 - Internet Securit Association Key Management Protocol (ISAKMP) 4 - IP Compression (IPCOMP) 255 - First Host (First Host in a chain) If the protocol identifier in the attributes is ISAKMP, the resulting policy is meant for a Phase 1 exchange. A Phase 1 exchange creates ISAKMP SAs which protect further negotiation traffic between the ISAKMP peers. If the protocol identifier in the attribute is a protocol type other than ISAKMP, the resulting policy is meant for use in a Phase 2 exchange. A Phase 2 exchange happens under the protection of a pre-existing Phase 1 SA, and negotiates a SA for the protocol specified in the attribute. Preference The specific preference for the stated protocol. Attribute Name: Transform Attribute Code: 278 Attribute Name: Encryption-Algorithm Attribute Code: 279 Attribute Name: Hash-Algorithm Attribute Code: 280 Attribute Name: Authentication-Mechanism Attribute Code: 281 Attribute Name: SA-Life-Seconds Attribute Code: 282 Attribute Name: SA-Life-Kbs Vakil, Calhoun expires September 1998 [Page 10] INTERNET DRAFT March 1998 Attribute Code: 283 Attribute Name: DH-Group Attribute Code: 284 Attribute Name: Key-Length Attribute Code: 285 Attribute Name: Key-Round Attribute Code: 286 Attribute Name: Encapsulation-Mode Attribute Code: 287 Attribute Name: Initiator-Id Attribute Code: 288 Attribute Name: Responder-Id Attribute Code: 289 Attribute Name: SA-Destination Attribute Code: 290 Attribute Name: Policy Attribute Code: 291 Attribute Name: Next-Hop Attribute Code: 292 Attribute Name: SA-Direction Attribute Code: 293 Attribute Name: Anti-Replay Attribute Code: 294 6.0 Attribute Meanings 6.1 Transform This attributes states the desired transform for the protocol. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Tag | Protocol | Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vakil, Calhoun expires September 1998 [Page 11] INTERNET DRAFT March 1998 | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type 278 for Transform Length 12 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same policy. This value is also used as a policy identifier. Protocol The Protocol field identifies for which protocol this attribute is to be used with as defined previously. Flag The Flag field has no meaning with this attribute. Preference The Preference field identifies the preference of the current transform within the proposal. The policy with the lowest preference value is prefered. Value The value field contains the transform ID. Note that this field is used in conjunction with the protocol ID in order to identify the specific transform. The following values are supported: 0 - NULL (ESP Only) 1 - DES (ESP and AH) 2 - 3DES (ESP Only) 3 - DES_IV64 (ESP Only) 4 - RC5 (ESP Only) 5 - IDEA (ESP Only) Vakil, Calhoun expires September 1998 [Page 12] INTERNET DRAFT March 1998 6 - CAST (ESP Only) 7 - Blowfish (ESP Only) 8 - 3IDEA (ESP Only) 9 - DES_IV32 (ESP Only) 10 - ARCFOUR (ESP Only) 11 - MD5 (AH Only) 12 - SHA-1 (AH Only) 13 - Oakley (ISAKMP Only) 14 - LZS (IPCOMP Only) 15 - V.42bis (IPCOMP Only) 16 - DEFLATE (IPCOMP Only) It is considered invalid to specify a value which is not relevant to the stated protocol ID in the attribute header. 6.2 Encryption-Algorithm This attribute states the desired encryption algorithm for ISAKMP phase 1 exchange. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Tag | Protocol | Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type 279 for Encryption-Algorithm Length 12 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same policy. This value is also used as a policy identifier. Protocol Vakil, Calhoun expires September 1998 [Page 13] INTERNET DRAFT March 1998 The Protocol field MUST be set to ISAKMP. Flag The Flag field has no meaning with this attribute. Preference The Preference field identifies the preference of the current policy. The policy with the lowest preference value is prefered. Value The value field contains the transform ID. Note that this field is used in conjunction with the protocol ID in order to identify the specific transform. The following values are supported: 1 - DES-CBC 2 - IDEA-CBC 3 - Blowfish-CBC 4 - RC5-R16-B64-CBC 5 - 3DES-CBC 6 - CAST-CBC 6.3 Hash-Algorithm This attribute states the desired hash algorithm for ISAKMP phase 1 exchange. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Tag | Protocol | Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type 280 for Hash-Algorithm Length Vakil, Calhoun expires September 1998 [Page 14] INTERNET DRAFT March 1998 12 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same policy. This value is also used as a policy identifier. Protocol The Protocol field MUST be set to ISAKMP. Flag The Flag field has no meaning with this attribute. Preference The Preference field identifies the preference of the current policy. The policy with the lowest preference value is prefered. Value The value field contains the transform ID. Note that this field is used in conjunction with the protocol ID in order to identify the specific transform. The following values are supported: 1 - MD5 2 - SHA 3 - Tiger 6.4 Authentication-Method This attributes states the desired authentication algorithm for the IPSEC protocols. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Tag | Protocol | Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vakil, Calhoun expires September 1998 [Page 15] INTERNET DRAFT March 1998 Attribute Type 281 for Authentication-Method Length 12 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same policy. This value is also used as a policy identifier. Protocol The Protocol field identifies for which protocol this attribute is to be used with as defined previously. Flag The Flag field has no meaning with this attribute. Preference The Preference field identifies the preference of the current policy. The policy with the lowest preference value is prefered. Value The value field contains the transform ID. Note that this field is used in conjunction with the protocol ID in order to identify the specific transform. The following values are supported: 1 - HMAC-MD5 (ESP and AH) 2 - HMAC-SHA-1 (ESP and AH) 3 - DES-MAC (ESP and AH) 4 - Pre-Shared key (ISAKMP Only) 5 - DSS-Signature (ISAKMP Only) 6 - RSA-Signature (ISAKMP Only) 7 - RSA-Encryption (ISAKMP Only) 8 - Revised-RSA-Encryption (ISAKMP Only) 9 - GSSAPI-Authentication (ISAKMP Only) 10 - KPDK (AH Only - MUST be used with MD5 as transform only) Vakil, Calhoun expires September 1998 [Page 16] INTERNET DRAFT March 1998 It is considered invalid to specify a value which is not relevant to the stated protocol ID in the attribute header. 6.5 SA-Life-Seconds This attributes states the lifetime for the generated Security Association for the IPSEC protocol requested. This attribute defines the lifetime in the number of seconds once the SA is established. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Tag | Protocol | Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type 282 for SA-Life-Seconds Length 12 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same policy. This value is also used as a policy identifier. Protocol The Protocol field identifies for which protocol this attribute is to be used with as defined previously. Flag The Flag field has no meaning with this attribute. Preference Vakil, Calhoun expires September 1998 [Page 17] INTERNET DRAFT March 1998 The Preference field identifies the preference of the current policy. The policy with the lowest preference value is prefered. Value The value field contains the number of seconds before the Security Association must be renegotiated. 6.6 SA-Life-Kbs This attributes states the lifetime for the generated Security Association for the IPSEC protocol requested. This attribute defines the lifetime in the number of kilobytes transmitted once the SA is established. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Tag | Protocol | Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type 283 for SA-Life-Kbs Length 12 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same policy. This value is also used as a policy identifier. Protocol The Protocol field identifies for which protocol this attribute is to be used with as defined previously. Vakil, Calhoun expires September 1998 [Page 18] INTERNET DRAFT March 1998 Flag The Flag field has no meaning with this attribute. Preference The Preference field identifies the preference of the current policy. The policy with the lowest preference value is prefered. Value The value field contains the number of kilobytes before the Security Association must be renegotiated. 6.7 DH-Group This attribute is used to indicate the Diffie-Hellman group for the phase 2 exchange. If perfect forward secrecy is desired, this attribute must be included. It allows for the negotiation of a fresh DH key for phase 2. This new ephemeral DH key can then be used instead of the phase 1 DH key, to derive session keys for the negotiated transforms. The attribute's format is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Tag | Protocol | Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type 284 for DH-Group Length 12 Tag Vakil, Calhoun expires September 1998 [Page 19] INTERNET DRAFT March 1998 The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same policy. This value is also used as a policy identifier. Protocol The Protocol field identifies for which protocol this attribute is to be used with as defined previously. This attribute is not valid for IPCOMP. Flag The Flag field has no meaning with this attribute. Preference The Preference field identifies the preference of the current policy. The policy with the lowest preference value is prefered. Value The value field contains the Diffie-Hellman group and may have one of the following values: 1 - First-Oakley-Group (MODP 768 bit) 2 - Second-Oakley-Group (MODP 1024 bit) 3 - Third-Oakley-Group (EC2N on GP[2^155]) 4 - Fourth-Oakley-Group (EC2N on GP[2^185]) 6.8 Key-Length For transforms that take variable length keys, this attribute can be used to indicate the key length desired. Its format is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Tag | Protocol | Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type Vakil, Calhoun expires September 1998 [Page 20] INTERNET DRAFT March 1998 285 for Key-Length Length 12 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same policy. This value is also used as a policy identifier. Protocol The Protocol field identifies for which protocol this attribute is to be used with as defined previously. This attribute is not valid for IPCOMP. Flag The Flag field has no meaning with this attribute. Preference The Preference field identifies the preference of the current policy. The policy with the lowest preference value is prefered. Value This field contains a non-zero length for the key. 6.9 Key-Round For transforms that have varying number of rounds, this attribute can be used to indicate the desired number of rounds. Its format is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Tag | Protocol | Preference | Vakil, Calhoun expires September 1998 [Page 21] INTERNET DRAFT March 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type 286 for Key-Rounds Length 12 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same policy. This value is also used as a policy identifier. Protocol The Protocol field identifies for which protocol this attribute is to be used with as defined previously. This attribute is not valid for IPCOMP. Flag The Flag field has no meaning with this attribute. Preference The Preference field identifies the preference of the current policy. The policy with the lowest preference value is prefered. Value This field contains a non-zero key round value. 6.10 Encapsulation-Mode This attribute indicates the encapsulation mode for the given protocol. The attribute's format is as follows: Vakil, Calhoun expires September 1998 [Page 22] INTERNET DRAFT March 1998 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Tag | Protocol | Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type 287 for Encapsulation-Mode Length 12 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same policy. This value is also used as a policy identifier. Protocol The Protocol field identifies for which protocol this attribute is to be used with as defined previously. Flag The Flag field has no meaning with this attribute. Preference The Preference field identifies the preference of the current policy. The policy with the lowest preference value is prefered. Value The value field may have one of the following values: 1 - Tunnel-Mode 2 - Transport-Mode Vakil, Calhoun expires September 1998 [Page 23] INTERNET DRAFT March 1998 6.11 Initiator-Id This attribute is used to indicate the identity of the ISAKMP exchange initiator. If the protocol field is ISAKMP, the identity is meant for a Phase 1 exchange (IDii in [4]). If the NAS happens to be the initiator, it knows its local identity. In this case, the attribute SHOULD not be sent in the Access-Accept. However, if the attribute is sent in the Access-Accept, the NAS has an option of ignoring it. If the attribute is not present in the Access-Accept, the NAS MUST assume that it is to provide its own identity. If the protocol field is anything but ISAKMP, the attribute provides the user identity on the initiator side for a Phase 2 exchange (IDui in [4]). 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Tag | Protocol | Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID Type | String... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type 288 for Initiator-Id Length >10 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same policy. This value is also used as a policy identifier. Protocol The Protocol field identifies for which protocol this attribute is to be used with as defined previously. This attribute is not valid for ISAKMP. Vakil, Calhoun expires September 1998 [Page 24] INTERNET DRAFT March 1998 Flag The Flag field has no meaning with this attribute. Preference The Preference field identifies the preference of the current policy. The policy with the lowest preference value is prefered. ID Type The ID Type field is one octet in length and represents the format of the address. The following values are supported: 1 - IPV4-Address (4 octets) 2 - IPV6-Address (20 octets) 3 - FQ-Domain-Name (e.g. 3com.com) 4 - FQ-User-Name (e.g. lobo@3com.com) 5 - IPV4-Subnet (4 octets address followed by 4 octets subnet mask) 6 - IPV4-Range (4 octets start address followed by by a 4 octet end address) 7 - X.500-Distinguished-Name 8 - X.500-General-Name 9 - Vendor-Specific (pre-shared key identity) String The string field contains the local identifier. 6.12 Responder-Id This attribute is used to indicate the identity of the ISAKMP exchange responder. If the protocol field is ISAKMP, the identity is meant for a Phase 1 exchange (IDir in [4]). If the NAS happens to be the responder, it knows its local identity. In this case, the attribute SHOULD not be sent in the Access-Accept. However, if the attribute is sent in the Access-Accept, the NAS has an option of ignoring it. If the attribute is not present in the Access-Accept, the NAS MUST assume that it is to provide its own identity. If the protocol field is anything but ISAKMP, the attribute provides the user identity on the responder side for a Phase 2 exchange (IDur in [4]). Vakil, Calhoun expires September 1998 [Page 25] INTERNET DRAFT March 1998 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Tag | Protocol | Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID Type | String... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type 289 for Remote-Id Length >10 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same Security Association Endpoint. Protocol The Protocol field identifies for which protocol this attribute is to be used with as defined previously. Flag The Flag field has no meaning with this attribute. Preference The Preference field identifies the preference of the current policy. The policy with the lowest preference value is prefered. ID Type The ID Type field is one octet in length and represents the format of the address. The following values are supported: 1 - IPV4-Address (4 octets) Vakil, Calhoun expires September 1998 [Page 26] INTERNET DRAFT March 1998 2 - IPV6-Address (20 octets) 3 - FQ-Domain-Name (e.g. 3com.com) 4 - FQ-User-Name (e.g. lobo@3com.com) 5 - IPV4-Subnet (4 octets address followed by 4 octets subnet mask) 6 - IPV4-Range (4 octets start address followed by by a 4 octet end address) 7 - X.500-Distinguished-Name 8 - X.500-General-Name 9 - Vendor-Specific (pre-shared key identity) Value The value field contains the remote identifier. 6.13 SA-Destination This attributes defines the destination address with which the Security Association will be established. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Tag | Protocol | Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type 290 for SA-Destination Length 12 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same Security Association Endpoint. Vakil, Calhoun expires September 1998 [Page 27] INTERNET DRAFT March 1998 Protocol The Protocol field has no meaning for this attribute. Flag The Flag field is used in order to identify the first host in a chain of Security Associations. The S bit is enabled if this host is the first security hop to the target. Note that this bit MUST be enabled even if the first hop is also the last hop. Preference The Preference field has no meaning for this attribute. Value The value field contains the address of the IPSEC destination, which may be the target host or an intervening Security Gateway. 6.14 Policy This attribute is used to reference a specific policy for the user. When more than a single instance of this attribute is present within a given tag, the preference field is used in order to identify the prefered policy. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Tag | Protocol | Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type 291 for Policy Length 12 Vakil, Calhoun expires September 1998 [Page 28] INTERNET DRAFT March 1998 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same Security Association Endpoint. Protocol The Protocol field has no meaning for this attribute. Flag The Flag field has no meaning with this attribute. Preference The Preference field identifies the preference of the stated policy. The policy with the lowest preference value is prefered. Value The Value field contains the policy identifier as described above. When used with the Preference field it is used in order to associate preferred policies to use for a given SA-Destination. 6.15 Next-Hop This attribute is used in order to identify the next hop in a chain of security associations. This attribute is used when it is necessary to establish a secure link with a security gateway in order to reach a host using IPSEC or in the case of multiple security gateways. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Tag | Protocol | Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type Vakil, Calhoun expires September 1998 [Page 29] INTERNET DRAFT March 1998 292 for Next-Hop Length 12 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same Security Association Endpoint. Protocol The Protocol field has no meaning for this attribute. Flag The Flag field has no meaning with this attribute. Preference The Preference field has no meaning with this attribute. Value The value field contains the address of the next hop. 6.16 SA-Direction A Phase 2 SA is unidirectional. This means that a pair of SAs are required to secure a session. If the NAS is initiating the Phase 2 SA exchange, it needs a set of protection suites that it can propose to its peer. On the other hand, if the NAS is responding to a Phase 2 SA exchange, it receives a set of protection suites from its peer. In this case, it needs a set of local protection suites to compare the proposed suites against. Hence it becomes necessary to provide the NAS with two sets of protection suites; one for use when it is the initiator, and the other when it is the responder. 0 1 2 3 Vakil, Calhoun expires September 1998 [Page 30] INTERNET DRAFT March 1998 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Tag | Protocol | Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type 293 for SA-Direction Length 12 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same Security Association Endpoint. Protocol The Protocol field has no meaning for this attribute. Flag The Flag field has no meaning with this attribute. Preference The Preference field has no meaning with this attribute. Value The value field contains the direction of the Security Association. The following values are supported: 1 - Initiator 2 - Reponder Vakil, Calhoun expires September 1998 [Page 31] INTERNET DRAFT March 1998 6.17 Anti-Replay The Anti-Replay attribute is used in order to identify whether anti- replay is to be used for the policy. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Tag | Protocol | Preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type 294 for Anti-Replay Length 12 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same policy. This value is also used as a policy identifier. Protocol The Protocol field identifies for which protocol this attribute is to be used with as defined previously. This attribute is only valid for ESP. Flag The Flag field has no meaning with this attribute. Preference The Preference field identifies the preference of the current policy. The policy with the lowest preference value is prefered. Vakil, Calhoun expires September 1998 [Page 32] INTERNET DRAFT March 1998 Value The value field may have one of the following values: 1 - Anti-Replay-Enabled 2 - Anti-Replay-Disabled 6.18 Table of Attributes The following table provides a guide to which of the above attributes may be found in which kinds of packets, and in what quantity. Authentication- Attribute Request Success Reject Number Name 0 0+ 0 278 Transform 0 0+ 0 279 Encryption-Algorithm 0 0+ 0 280 Hash-Algorithm 0 0+ 0 281 Authentication-Mechanism 0 0+ 0 282 SA-Life-Seconds 0 0+ 0 283 SA-Life-Kbs 0 0+ 0 284 DH-Group 0 0+ 0 285 Key-Length 0 0+ 0 286 Key-Round 0 0+ 0 287 Encapsulation-Mode 0 0+ 0 288 Initiator-Id 0 0+ 0 289 Responder-Id 0 0+ 0 290 SA-Destination 0 0+ 0 291 Policy 0 0+ 0 292 Next-Hop 0 0+ 0 293 SA-Direction 0 0+ 0 294 Anti-Replay The following table defines the meaning of the above table entries. 0 This attribute MUST NOT be present in packet. 0+ Zero or more instances of this attribute MAY be present in packet. 0-1 Zero or one instance of this attribute MAY be present in packet. 7.0 References [1] P. R. Calhoun, A. Rubens, "DIAMETER Base Protocol", draft-calhoun-diameter-00.txt, February 1998. [2] C. Zorn, D. Leifer, John Shriver, "RADIUS Attributes for Tunnel Protocol Support", Internet Draft, July 1997. Vakil, Calhoun expires September 1998 [Page 33] INTERNET DRAFT March 1998 [3] K. Hamzeh, T. Kolar, M. Littlewood, G. Singh Pall, J. Taarud, A. J. Valencia, W. Verthein, W.M. Townsley, B. Palter, A. Rubens "Layer Two Tunneling Protocol (L2TP)", Internet Draft, October 1997 [4] D. Harkins D., D. Carrel, "The Resolution of ISAKMP with Oakley", Internet Draft, July 1997 [5] D. Maughan, M. Schertler, M. Schneider, J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", Internet Draft, July 1997 [6] D. Piper, "The Internet IP Security Domain Of Interpretation for ISAKMP",Internet Draft, October 1997 [7] S. Kent, R. Atkinson, "IP Encapsulating Security Payload", Internet Draft, October 1997 [8] S. Kent, R. Atkinson, "IP Authentication Header", Internet Draft, October 1997 [9] R. Atkinson, "Security Architecture for the Internet Protocol", RFC 1825, August 1995 [10] J. Reynolds, J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994 [11] P. R. Calhoun, "DIAMETER Authentication Extension", draft-calhoun-diameter-auth-00.txt, February 1998. 8.0 Author's Address Questions about this memo can also be directed to: Sumit A. Vakil 3Com Corporation 1800 W. Central Rd. Mount Prospect, Il, 60056 USA Phone: 1-847-342-6892 Fax: 1-847-222-2424 E-mail: Sumit_Vakil@MW.3Com.Com Pat R. Calhoun Technology Development Sun Microsystems, Inc. 15 Network Circle Vakil, Calhoun expires September 1998 [Page 34] INTERNET DRAFT March 1998 Menlo Park, California, 94025 USA Phone: 1-847-548-9587 Fax: 1-650-786-6445 E-mail: pcalhoun@toast.net Vakil, Calhoun expires September 1998 [Page 35]