HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 09:44:20 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Thu, 24 Jun 1999 17:37:39 GMT ETag: "2e6bde-11e8e-37726ce3" Accept-Ranges: bytes Content-Length: 73358 Connection: close Content-Type: text/plain INTERNET-DRAFT Fergal Ladley expires on 23 December 1999 Ericsson 23 June 1999 A DIAMETER-based Authentication and Access Control Protocol Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract This document specifies a DIAMETER-based protocol which may be used to authenticate and perform access control of users on an IP network. The protocol allows mutual authentication of a user and a network and a means based on the IPSec Authentication Header for the network to deny access to unauthorised users. Table of Contents 1.0 Introduction 2.0 Terminology 3.0 Description of protocol operation 3.1 Access control 3.2 Network authentication 3.3 User authentication 3.3.1 A note on location privacy 3.4 Authorisation 3.5 Detailed specification of protocol operation 4.0 Command Codes 4.1 Access-Request 4.2 Access-Response 4.2.1 Failure of authentication/authorisation 4.2.2 Success of authentication/authorisation Ladley Expires 23 December 1999 [Page 1] INTERNET DRAFT 23 June 1999 4.3 IPSec-SA-Setup 5.0 DIAMETER AVPs 5.1 Message-Authentication-Code 5.2 Network-Access-Identifier 5.3 Sequence-Number 5.4 Home-AAA-IP-Address 5.5 Router-IP-Address 5.6 Public-Key-Security-Association 5.7 Secret-Key-Security-Association 5.8 Session-Key 5.9 SA-Source AVP 6.0 Security considerations 7.0 Performance considerations 8.0 References 9.0 Acknowledgements 10.0 Author's address 1.0 Introduction In many networks it is quite a simple matter for a user who is not authorised to use the network to attach a node, acquire an IP address and learn the address of a router. In such a fashion may unauthorised access to an IP network be obtained. This may provide the user with free Internet access or unauthorised access to a private internet (a so-called 'intranet') which may be useful for purposes of espionage. It also facilitates hostile acts such as denial of service attacks which cannot easily be traced to the attacker. Therefore it is desirable that the network operator be able to authenticate users and hinder unauthenticated or unauthorised users from using the network. It is important not only that the network can be aware of the presence and identity of the user but also that the user can know the identity of the network operator. This is required so that the user can make decisions regarding network usage (e.g. regarding transmission of sensitive information over that network and whether and how much to use the network). Particularly in the case of wireless networks such as IEEE 802.11, there may be few readily perceptible indicators of the identity of the operator. This document specifies a protocol which uses the DIAMETER [1] protocol and the IPSec Authentication Header [2] as means to prevent IP datagrams from unauthorised users from being routed beyond the link from which they originate. Due to the facts that this protocol is intended to work over any link layer and that some link layers, such as Ethernet, do not have any authentication mechanisms, this protocol does not specify a means of controlling access to nodes on Ladley Expires 23 December 1999 [Page 2] INTERNET DRAFT 23 June 1999 the same link as the node of the user under authentication. This protocol may be of use where mobile IP is used. In mobile IPv4 [3], it may be possible to simply ignore the foreign agent and use a co-located care-of address. In mobile IPv6 [4], there is no foreign agent, so it may be difficult for the network operator to be aware of the presence of a user, let alone of that user's identity. This would render charging for the use of the network difficult. Use of the protocol defined in this document would render the sending of Registration Requests or Binding updates over the foreign network infeasible for unauthorised users. This protocol attempts to minimise the number and size of messages sent to and from the user's node. The reason for this is that it is thought likely that the user's node may be a battery-powered device connected via a radio link which typically has a low bit rate and a high bit error rate. Therefore it is desirable to minimise power consumption and number of bits sent over the radio interface. The problems of the cellular radio interface are discussed in [16]. Note that a distinction is made between a node and its user. It may be supposed that the identity of the user is of more interest than the identity of the node in use; usually, it is the user who must be authenticated, not his terminal. A Network Access Identifier (NAI) [6] is used to identify a user. A user may be physically instantiated by, say, a smart card. In this protocol the card would have to store a NAI, a secret key and a sequence number and and be able to execute message digest and cryptographic algorithms. 2.0 Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [5]. AAA server A node which handles AAA processing. In this protocol, an AAA server is a node which can accept and process Access-Request messages and generate and send IPSec-SA-Setup and Access-Response messages. A user's 'home AAA server' is an AAA server with which the user shares a secret. Such an AAA server is able to authenticate the user. A user can have arbitrarily many home AAA servers, using the same identity (NAI) at multiple AAA servers and different identities (NAIs) at the same AAA server. A user's 'local AAA server' is an AAA server in the domain in Ladley Expires 23 December 1999 [Page 3] INTERNET DRAFT 23 June 1999 which the user is currently present. If a local AAA server is unable to authenticate a user it asks the user's home AAA server to do so. access control The practice of restricting access to resources. In this protocol, the resource is the IP forwarding capability of the first-hop router. first-hop router A router attached to the same link as the node and which the node uses to route traffic that is not destined for other nodes on the same link. user node an IP node which the user under authentication and authorisation is using to attach to the local link in question. IP Internet Protocol. In this document, the term 'IP' may be interpreted either as IPv4 or as IPv6 unless suffixed with 'v4' or 'v6'. Ka A secret shared between only the home AAA server and the local AAA server. Kc A session key generated in the home AAA server and distributed to the local AAA server, the user node and the user node's first-hop router. Ki A secret shared between only the user of the user node and the home AAA server. Kr A secret shared between only a local AAA server and a local router. Ladley Expires 23 December 1999 [Page 4] INTERNET DRAFT 23 June 1999 location privacy The principle of not disclosing the location of a user. user A (probably human) entity which uses a user node as an interface to a network. A user is uniquely identified by a NAI and shares a secret with and is trusted by some AAA server (a home AAA server for that user). 3.0 Description of protocol operation This protocol has four major parts: - access control - network authentication - user authentication - authorisation The protocol uses DIAMETER and operates over UDP. The DIAMETER Reliable Transport Extensions [12] are used for reliability. Here is a diagram showing the typical message sequence: user node router local AAA home AAA | | | | | | | | |-------------------- Access-Request ----->| | | | | | | | | | | | |--- Access-Request --->| | | | | | | | | | | |<-- Access-Response ---| | | | | | | | | | |<--- IPSec-SA-Setup --| | | | | | | | | | |<-------------------- Access-Response --- | | | | | | | | | | |--IP packet w/ AH->| | | |--IP packet w/ AH->| | | | | | | Ladley Expires 23 December 1999 [Page 5] INTERNET DRAFT 23 June 1999 In sections 3.1 through 3.4 we will outline the operation of the protocol. In these sections, completeness has occasionally been sacrificed for the sake of readability. In section 3.5 we will specify in full detail the operation of the protocol. 3.1 Access Control As mentioned in section 1.0, the nature of some link layers makes it difficult to perform access control. For example, there is nothing in Ethernet to stop a node from attaching to an Ethernet segment and communicating with other nodes on that segment. However, useful access control may be performed at the network layer. By use of packet filtering in the user node's first-hop router, it is possible to prevent IP datagrams from a user node from being routed beyond the link to which it is attached and to prevent IP datagrams addressed to a node from being routed onto the link to which it is attached. This restricts the node to being able to use IP to communicate only with other nodes on the same link as itself. Such communication may be controlled using methods outside the scope of this document. Packets from the node are filtered based on a combination of destination IP address (in the outer IP header) and IPSec Authentication Header [2]. Upon receipt of a datagram from the user node, the user node's first-hop router checks the address of the ultimate destination of the datagram. If this is one of a set of excepted addresses, the router strips off the outer header (if present) and forwards the datagram. The set of excepted addresses includes addresses of all nodes that are not attached to the same link as the user node but which must be reachable from the user node before user authentication. Such addresses might be of a local AAA server, a local DHCP server and any off-link nodes which local conditions require be reachable from the user node before user authentication. The AH is used in tunnel mode; the router is the security gateway. The IP datagram looks essentially like this: source destination source destination +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UN addr | router addr | AH | UN addr | U. addr | IP payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <--------- outer header --------><--- datagram to be forwarded ---> Ladley Expires 23 December 1999 [Page 6] INTERNET DRAFT 23 June 1999 where AH = Authentication Header, UN = User Node and U. addr is the address of the ultimate destination of the datagram. If the destination address of the inner IP header is not a member of the set of excepted addresses, the router checks the Integrity Check Vector (ICV) in the AH. If the ICV is absent or incorrect, the datagram is dropped. If a router receives a datagram addressed to a user node whose user has not been authenticated and authorised and the source address of the datagram is not one of the set of excepted addresses, the router drops the datagram. 3.2 Network authentication It is important that the user can know who operates a network which is available to him. A user may be unwilling to use a network operated by a particular party. This might be because the operator is likely to act in some way hostile to the user, such as eavesdropping or traffic analysis, or simply because the user does not agree with the conditions of use of the network. For this reason, this protocol allows - but does not require - the user to authenticate the network. It is supposed that a user may wish to withhold his identity from an untrusted network. Therefore network authentication MAY be performed before user authentication and without disclosure of the user's identity to an untrusted entity. Network authentication is performed using either public key cryptography or secret key cryptography. It is envisaged that public key cryptography will be used when a user uses a user node outside his home domain (the local AAA server is not a home AAA server for that user) and that secret key cryptography will be used when a user uses a user node inside his home domain (the local AAA server is a home AAA server for that user). In order to authenticate the network, a user node must possess a public key certificate of, or share a secret with, an AAA server in that network. The authentication is performed by encrypting the NAI in the Access-Request message. Only the party identified by the certificate or sharing the secret will be able to decrypt the NAI and continue the protocol. If, for example, the user obtained a certificate from the AAA server and the AAA server returned a certificate of some other entity, it would subsequently be unable to decrypt the NAI and would neither be able to continue the protocol convincingly nor learn the identity of the user. A further advantage of encryption of the NAI is that it prevents disclosure of the user's identity to parties eavesdropping on the Ladley Expires 23 December 1999 [Page 7] INTERNET DRAFT 23 June 1999 link and thus aids location privacy. 3.3 User Authentication After the network has, if so desired by the user, been authenticated, the user node must then identify its user to a local AAA server, so that it can authenticate the user or request the user's home AAA server to authenticate the user. The user's identity is encoded as a NAI. The user node sends an Access-Request containing the (possibly encrypted) NAI, a sequence number (which is used to check whether the message is a replay), a Message Authentication Code (MAC) computed with the key the user shares with his home AAA server to a local AAA server (which may be a home AAA server of the user). The NAI may be encrypted with a public key of the local AAA server or a secret key shared between the user and the local AAA server. The local AAA server decrypts the NAI (if encrypted) and checks whether it shares a secret with the user identified by that NAI. If it does, it checks the sequence number and MAC in the Access-Request. If the sequence number and MAC are valid, it sends an IPSec-SA-Setup message to the user node's router which contains the following information necessary to set up an IPSec security association (SA) [7] from the user node to the router: - a Security Parameters Index (SPI) - the IP address of the user node - the algorithm to use for ICV computation in the AH - a session key, Kc (suitably encrypted) - the lifetime of the SA - whether or not to enable AH replay protection It then sends an Access-Response to the user node which contains the following information necessary to set up an IPSec security association (SA) from the user node to the router: - the SPI - the IP address of the router - the algorithm to use for ICV computation in the AH - Kc (suitably encrypted) Ladley Expires 23 December 1999 [Page 8] INTERNET DRAFT 23 June 1999 - the lifetime of the SA - whether or not the router will enable AH replay protection Upon receipt of the IPSec-SA-Setup message, the router creates an IPSec SA. From this point, the router will forward datagrams from the user node. Upon receipt of the Access-Response, the user node creates an IPSec SA. From this point, datagrams sent from the user node - other than those addressed to excepted addresses as described in 3.1 - should contain a tunnel-mode AH as described in 3.1. If the local AAA server does not share a secret with the user identified in the Access-Request, it proxies [13] the Access-Request to an AAA server which does. This AAA server then processes the Access-Request as described above and returns an Access-Response to the local AAA server which then constructs and sends a IPSec-SA-Setup message to the user node's router before proxying the Access-Response to the user node. 3.3.1 A note on location privacy. The purpose of encryption of the Network-Access-Identifier AVP is to prevent the disclosure of the user's identity to eavesdroppers. Note that disclosure of the NAI contained in this AVP does not necessarily imply disclosure of the identity of some human. For example, the NAI 85434@bigcorp.com does not identify John Doe, CEO of Bigcorp, to any entity which does not know that 85434@bigcorp.com is a NAI of John Doe, CEO of Bigcorp. However, the NAI John_Doe_CEO@bigcorp.com rather obviously discloses the identity of the human associated with that NAI. Furthermore, even if a third party cannot associate a particular human with the NAI 85434@bigcorp.com, the fact that a person associated with Bigcorp visited the network may be of interest to a third party. The moral of the story is: if you care about location privacy, encrypt your NAI. 3.4 Authorisation In this protocol the resource which is controlled is IP forwarding. Authorisation to use this resource may be performed in the home AAA server or the local AAA server. For example, upon receipt of an Access-Request, a local AAA server can decide to grant or deny access to the user based soley on the identity claimed by the NAI. A home AAA server can decide to grant or deny access to the local network based on the identity claimed by the NAI or based on some information in the user profile for that NAI. Ladley Expires 23 December 1999 [Page 9] INTERNET DRAFT 23 June 1999 3.5 Detailed specification of protocol operation. The operation of the protocol is as follows: 1. A user node performs a link-layer attach to the local network. 2. The user node acquires an IP address. 3. The user node learns an IP address of a local AAA server. 4. The user node sends an Access-Request to the local AAA server. The Network-Access-Identifier AVP in this message MAY be in one of the following three formats: - encrypted with a public key of the local AAA server - encrypted with a secret key shared between only the user of the user node and the local AAA server - plaintext. 5. Upon receipt of an Access-Request, an AAA server MUST perform the following sequence of actions: 5a) It checks that the Access-Request is formed according to the specification in 4.1. If it is not, it MUST send a Message-Reject-Ind [1] to the node from which it received the Access-Request and discontinue further processing of the Access-Request. Otherwise, it proceeds to 5b. 5b) If the Network-Access-Identifier AVP in the Access-Request is not encrypted, it proceeds to 5c. If it is encrypted and at least one of the following conditions holds: - the Access-Request contains a Router-IP-Address AVP (i.e. it comes from a user node in the local domain) - the Access-Request contains a Home-AAA-IP-Address equal to an IP address of the AAA server (i.e. the AAA server is a home AAA server of the user identified by the NAI in the Access-Request) it attempts to decrypt the Network-Access-Identifier AVP. If the attempt fails, it MUST send a Message-Reject-Ind to the node from which it received the Access-Request and discontinue further processing of the Access-Request. If the attempt succeeds, or neither of the two conditions stated above hold, it proceeds to 5c. 5c) If the AAA server now has a plaintext NAI, it checks whether Ladley Expires 23 December 1999 [Page 10] INTERNET DRAFT 23 June 1999 or not it shares a secret with the user identified by the NAI. If it does not have a plaintext NAI, or it does not share a secret with the user identified by the NAI, it checks for the presence of a Home-AAA-IP-Address AVP in the Access-Request. If one is present, it proxies the Access-Request to that address. If no Home-AAA-IP-Address AVP is present in the Access-Request and the AAA server has a plaintext NAI, it attempts to deduce an IP address of a home AAA server for the NAI from the NAI. If this attempt fails, or the AAA server does not have a plaintext NAI, it MUST return an Access-Response with an Error-Code AVP with a value of DIAMETER_HOME_AAA_SERVER_UNREACHABLE to the node from which it received the Access-Request and discontinue further processing of the Access-Request. If this attempt succeeds, it proxies the Access-Request to the address deduced. If the Access-Request contains a Router-IP-Address AVP (i.e. it comes from a user node in the local domain) and the Network-Access-Identifier AVP was encrypted, the AAA server MUST encrypt the Network-Access-Identifier AVP with either a public key of the home AAA server or a secret key shared between only the AAA server and the home AAA server. If the Network-Access-Identifier AVP was not encrypted, the AAA server MAY encrypt the Network-Access-Identifier AVP with either a public key of the home AAA server or a secret key shared between only the AAA server and the home AAA server. If the AAA server does share a secret with the user identified by the NAI, it checks the sequence number in the Access-Request and compares it with the expected sequence number as described in 3.6.1. If the received sequence number is less than the expected sequence number, the Access-Request MUST be silently discarded. Otherwise, the message authentication code (MAC) of the Access-Request is computed. If the computed MAC is not equal to the received MAC, the Access-Request MUST be silently discarded. Otherwise, the Access-Request is valid and processing proceeds to 5d. 5d) If an AAA server has received a valid Access-Request from a user of which it is a home AAA server, it should - in the absence of any particular reason not to do so - return an Access-Response to the AAA server whose address was given in the Host-IP-Address AVP in the Access-Request. This is formed according to the definition in 4.2. The value of the Sequence-Number AVP MUST be equal to the value of the Sequence-Number AVP in the Access-Request. It is required that the home AAA server have secure access to Ladley Expires 23 December 1999 [Page 11] INTERNET DRAFT 23 June 1999 a high-quality random number generator for session key generation. 5e) After determining that a received Access-Request is valid and before processing another Access-Request, a home AAA server MUST increment its sequence number so that it is one greater than the value of the Sequence-Number AVP in the Access-Request whose validity has been determined. 6. Upon receipt of an Access-Response, the local AAA server MUST perform the following sequence of actions: 6a) It checks that the Access-Response is formed according to the specification in 4.2. If it is not, it MUST send a Message-Reject-Ind to the node from which it received the Access-Response and discontinue further processing of the Access-Response. Otherwise, it proceeds to 6b. 6b) If the Access-Response does not contain two Session-Key AVPs (i.e. authentication/authorisation failed at the home AAA server) as described in 4.2.2, the local AAA server proxies the Access-Response to the user node. If the Access-Response contains two Session-Key AVPs as described in 4.2.2, the local AAA server attempts to decrypt the first. If the attempt fails, it MUST send a Message-Reject-Ind to the node from which it received the Access-Response and discontinue further processing of the Access-Response. If the attempt succeeds, it MUST generate an IPSec-SA-Setup message and send it to the user node's first-hop router (whose address was taken from the Router-IP-Address AVP in the Access-Request). The Session-Key AVP in the IPSec-SA-Setup message MUST be encrypted so as to be decryptable by the router. The SA-Source AVP in the IPSec-SA-Setup message MUST contain the IP address of the user node. 6c) It adds a Transform AVP, Auth-Method AVP, SA-Life-Seconds AVP, SA-Life-Kbs AVP, SA-Destination AVP and an Anti-Replay AVP (all of which are defined in [8]) and proxies it to the user node. 7. Upon receipt of an IPSec-SA-Setup message, a router MUST perform the following sequence of actions: 7a) It checks that the IPSec-SA-Setup is formed according to the specification in 4.3. If it is not, it MUST send a Message-Reject-Ind to the node from which it received the IPSec-SA-Setup and discontinue further processing of the IPSec-SA-Setup. Otherwise, it proceeds to 7b. Ladley Expires 23 December 1999 [Page 12] INTERNET DRAFT 23 June 1999 7b) It attempts to decrypt the Session-Key AVP. If the attempt fails, it MUST send a Message-Reject-Ind to the node from which it received the Access-Request and discontinue further processing of the Access-Request. Otherwise it proceeds to 7c. 7c) It sets up an IPSec security association according to the data contained in the IPSec-SA-Setup message. At this point, the router will forward IP datagrams which it receives addressed to the user node. 8. Upon receipt of an Access-Response, a user node MUST perform the following sequence of actions: 8a) It checks that the Access-Response is formed according to the specification in 4.2. If it is not, it MUST send a Message-Reject-Ind to the node from which it received the Access-Request and discontinue further processing of the Access-Request. Otherwise, it proceeds to 8b. 8b) It checks the sequence number in the Access-Response an compares it with the sequence number in the last Access-Request it sent. If the two are not equal, the Access-Response MUST be silently discarded. Otherwise, the message authentication code (MAC) of the Access-Response is computed. If the computed MAC is not equal to the received MAC, the Access-Response MUST be silently discarded. Otherwise, the Access-Response is valid and processing proceeds to 8c. 8c) If the Result-Code AVP in the Access-Response is not equal to zero, the user node takes some appropriate action (such as displaying an error message to the user) and discontinues further processing of the Access-Response. Otherwise, it proceeds to 8d. 8d) It sets up an IPSec security association according to the data contained in the Access-Response. At this point, the user node can send authenticated IP datagrams via its first-hop router. 3.6 Use of the sequence number The Access-Request and Access-Response messages contain a sequence number. This is used for replay protection between the user and the home AAA server, in both directions. When the shared secret (Ki) between a user and a home AAA server is established, the sequence number is equal to zero. If a user has multiple NAIs with the same AAA server, a separate sequence number MUST be associated with each. Ladley Expires 23 December 1999 [Page 13] INTERNET DRAFT 23 June 1999 3.6.1 Sequence number handling by the home AAA server Upon receipt of an Access-Request, the home AAA server compares the received sequence number with its own value of the sequence number (the expected sequence number). If the received sequence number is less than the expected sequence number, the Access-Request MUST be silently discarded. If the received sequence number is greater than or equal to the expected sequence number, processing of the Access-Request proceeds to MAC verification. If the MAC is valid, the expected sequence number is incremented so that it is one greater than the received sequence number. 3.6.2 Sequence number handling by the user After sending an Access-Request and before sending another, the user increments the value of the sequence number by one. Hence the first Access-Request has a sequence number of zero and each subsequent Access-Request has a sequence number one greater than the previous Access-Request. If the user has sent an Access-Request with a sequence number of 2^32, he MUST NOT send another Access-Request before establishing a new shared secret (Ki) with the home AAA server. Upon establishment of a new shared secret, the sequence number is reset to zero. Upon receipt of an Access-Response, a user compares the received sequence number with the sequence number in the last Access-Request he sent. If the received sequence number is not equal to the sequence number in the last Access-Request it sent, the Access-Response MUST be silently discarded. 4.0 Command Codes The DIAMETER-Command AVP is defined in [1]. The following commands are instances of the DIAMETER-Command AVP. Command Name Command Code -------------------------------------- Access-Request N Access-Response N+1 IPSec-SA-Setup N+2 4.1 Access-Request Description The Access-Request is generated by a user node and sent to a local Ladley Expires 23 December 1999 [Page 14] INTERNET DRAFT 23 June 1999 AAA server, from where it may be proxied to a home AAA server. The Access-Request MUST contain a Network-Access-Identifier AVP which uniquely identifies the user of the user node. The Network-Access-Identifier AVP MAY be encrypted either with a public key of the AAA server to which it will be sent or with a secret key shared between only the sender (which may be the user of the user node or an AAA server in the proxy chain from the local AAA server to the home AAA server) and the home AAA server. If it is encrypted with a public key, the following conditions MUST hold: - the Network-Access-Identifier AVP is immediately succeeded by a Public-Key-Security-Association AVP - the 'AVP Index' field in the Public-Key-Security-Association AVP has a value of 2 If it is encrypted with a secret key, the following conditions MUST hold: - the Network-Access-Identifier AVP is immediately succeeded by a Secret-Key-Security-Association AVP - The 'AVP Index' field in the Secret-Key-Security-Association AVP has a value of 2 The Access-Request MUST contain a Sequence-Number AVP which is used for replay protection of traffic between the user node and the home AAA server. See 3.6 for further information on replay protection. When sent from the user node, the Access-Request MAY contain a Home-AAA-IP-Address AVP containing an IP address of a home AAA server. If present, the address in this AVP SHOULD be used by the local AAA server to address the home AAA server. Otherwise, the local AAA server MUST either deduce the IP address of the home AAA server from the Network-Access-Identifier AVP or proxy the Access-Request to an AAA server which can proxy it further to the home AAA server. If the Access-Request is being proxied from a local AAA server to a home AAA server, it MUST include a Home-AAA-IP-Address AVP in order for proxy servers in the proxy chain to be able to 'route' the Access-Request and so that the destination (the home AAA server) knows that the message is for it and can process it accordingly. When sent from the user node, the Access-Request MUST contain a Router-IP-Address AVP containing the IP address of the user node's first-hop router. The local AAA server needs this Ladley Expires 23 December 1999 [Page 15] INTERNET DRAFT 23 June 1999 information in order to set up an IPSec security association between the router and the user node. The local AAA server MUST remove this AVP from the Access-Request before proxying it further. The Access-Request MUST contain a Host-IP-Address AVP. When sent from the user node, this AVP MUST contain an IP address of the user node. When sent from the local AAA server, this MUST contain an IP address of that server. Because the home AAA server must be able to authenticate the origin of and check the integrity of the Access-Request, there MUST be present a Message-Authentication-Code AVP which contains a MAC computed using Ki over the following sequence: [<Sequence-Number AVP>] The value of the Session-Id AVP is chosen by the user node and this value MUST be used in the Session-Id AVP in the subsequent Access-Response. Message Format <Access-Request> ::= <DIAMETER Header> <Access-Request Command AVP> <Session-Id AVP> <Network-Access-Identifier AVP> {<Public-Key-Security-Association AVP> XOR <Secret-Key-Security-Association AVP>} [<Router-IP-Address>] [<Home-AAA-IP-Address AVP>] <Host-IP-Address> <Sequence-Number AVP> <Message-Authentication-Code AVP> AVP Format The Access-Request Command AVP is shown below. The fields are transmitted from right to left. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | Reserved |P|T|V|E|H|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ladley Expires 23 December 1999 [Page 16] INTERNET DRAFT 23 June 1999 AVP Code 256 DIAMETER-Command AVP Length The length of this AVP must be 12. AVP Flags The 'M' bit must be set. The 'P', 'T', 'V', 'E' and 'H' bits MUST NOT be set. Command Code The Command Code field must be set to N (Access-Request). 4.2 Access-Response Description The Access-Response is generated by a home AAA server and sent to a user node by proxying through a local AAA server. If the home AAA server is also the local AAA server it indicates whether or not the AAA server has authorised the user of the user node to use the network. If the home AAA server is not the local AAA server, it indicates whether or not the home AAA server and the local AAA server have authorised the user of the user node to use the network. In both cases, if the user is authorised, the Access-Response contains the information necessary for the user node to set up an IPSec security association with its first-hop router. The value of the Session-Id AVP is taken from the Access-Request. The Access-Response includes the Result-Code AVP to indicate whether or not the request was successful. If the Result-Code AVP has a value of 5 there MUST be present an Error-Code AVP. The following error codes are defined for this command: DIAMETER_HOME_AAA_SERVER_UNREACHABLE 1 This error code indicates that the AAA server whose IP address was either deduced from the NAI in the Access-Request or taken from the Home-AAA-IP-Address AVP in the Access-Request could not be reached at that address, or Ladley Expires 23 December 1999 [Page 17] INTERNET DRAFT 23 June 1999 that a home AAA server could not be identified. DIAMETER_UNKNOWN_USER 2 This error code indicates that the AAA server indicated in the Access-Request as a home AAA server of the user indicated by the NAI in the Access-Request has no record of a user identified by that NAI. DIAMETER_AUTHENTICATION_FAILED 3 This error code indicates that the home AAA server has a record of a user identified by the NAI given in the Access-Request but was unable to authenticate the user. DIAMETER_AUTHORISATION_REFUSED 4 This error code indicates that the local AAA server or the home AAA server has refused to authorise the user. This may happen if, for example, the local AAA server is directed by local policy to refuse authorisation to a particular user or to all users from a certain domain. 4.2.1 Failure of authentication/authorisation Because the user of the user node must be able to authenticate the origin of and check the integrity of the Access-Response, there MUST be present a Message-Authentication-Code AVP computed using Ki over the following sequence: [<Access-Response AVP><Session-Id AVP><Sequence-Number AVP> <Result-Code AVP><Error-Code AVP (if present)>] Message Format <Access-Response> ::= <DIAMETER Header> <Access-Response Command AVP> <Session-Id AVP> <Sequence-Number AVP> <Result-Code AVP> [<Error-Code AVP>] <Message-Authentication-Code AVP> 4.2.2 Success of authentication/authorisation When the Access-Response arrives at the local AAA server, it contains two Session-Key AVPs. The first is encrypted with either a public key of the local AAA server or a secret key shared between only the home AAA server and the local AAA server. Ladley Expires 23 December 1999 [Page 18] INTERNET DRAFT 23 June 1999 If it is encrypted with a public key of the local AAA server, the following two conditions MUST hold: - it is immediately followed by a Public-Key-Security-Association AVP - the 'AVP Index' field of the Public-Key-Security-Association AVP has a value of 4 If it is encrypted with a secret key shared between only the local AAA server and the home AAA server, the following conditions MUST hold: - it is immediately followed by a Secret-Key-Security-Association AVP - the 'AVP Index' field of the Secret-Key-Security-Association AVP has a value of 4 The second is encrypted with Ki. The following conditions MUST hold: - it is immediately followed by a Secret-Key-Security-Association AVP - the 'AVP Index' field of the Secret-Key-Security-Association AVP has a value of 6 There MUST be present a Message-Authentication-Code AVP computed using Ki over the following sequence: [<Access-Response Command AVP><Session-Id AVP> <Sequence-Number AVP><Result-Code AVP><second Session-Key AVP> <last Secret-Key-Security-Association>] Message Format 1. From the home AAA server to the local AAA server: <Access-Response> ::= <DIAMETER Header> <Access-Response Command AVP> <Session-Id AVP> <Sequence-Number AVP> <Result-Code AVP> <Session-Key AVP> {<Secret-Key-Security-Association AVP> XOR <Public-Key-Security-Association>} <Session-Key AVP> <Secret-Key-Security-Association> <Message-Authentication-Code AVP> Ladley Expires 23 December 1999 [Page 19] INTERNET DRAFT 23 June 1999 2. From the local AAA server to the user node: <Access-Response> ::= <DIAMETER Header> <Access-Response Command AVP> <Session-Id AVP> <Sequence-Number AVP> <Result-Code AVP> <Session-Key AVP> <Secret-Key-Security-Association AVP> <Security-Parameters-Index AVP> <Transform AVP> <Auth-Method AVP> <SA-Life-Seconds AVP> <SA-Life-Kbs AVP> <SA-Destination AVP> <Anti-Replay AVP> <Message-Authentication-Code AVP> AVP Format The Access-Request Command AVP is shown below. The fields are transmitted from right to left. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | Reserved |P|T|V|E|H|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Code 256 DIAMETER-Command AVP Length The length of this AVP must be 12. AVP Flags The 'M' bit must be set. The 'P', 'T', 'V', 'E' and 'H' bits MUST NOT be set. Command Code The Command Code field MUST be set to N+1 (Access-Response). Ladley Expires 23 December 1999 [Page 20] INTERNET DRAFT 23 June 1999 4.3 IPSec-SA-Setup Description The IPSec-SA-Setup is sent to the user node's first-hop router by a local AAA server. It contains the data necessary for the router to set up an IPSec security association from the user node to itself. The Session-Key AVP MUST be encrypted with either Kr or a public key of the router. If it is encrypted with Kr, the following conditions MUST hold: - it is immediately succeeded by a Secret-Key-Security-Association AVP - the 'AVP Index' field of the Secret-Key-Security-Association AVP has a value of 1 If it is encrypted with a public key of the router, the following conditions MUST hold: - it is immediately followed by a Public-Key-Security-Association AVP - the 'AVP Index' field of the Public-Key-Security-Association AVP has a value of 1 There MUST be present a Host-IP-Address AVP and a Timestamp AVP. It MUST contain either a Message-Authentication-Code AVP computed using Kr over the following sequence: [<DIAMETER Header><IPSec-SA-Setup Command AVP><Session-Key AVP> <Public-Key-Security-Association AVP XOR Secret-Key-Security-Association AVP><Transform AVP> <Auth-Method AVP><SA-Life-Seconds AVP><SA-Life-Kbs AVP> <SA-Source AVP><Anti-Replay AVP><Host-IP-Address AVP> <Timestamp AVP>] or a Digital-Signature AVP, in which case there must be a Nonce AVP present. Ladley Expires 23 December 1999 [Page 21] INTERNET DRAFT 23 June 1999 Message Format <IPSec-SA-Setup> :== <DIAMETER Header> <IPSec-SA-Setup Command AVP> <Session-Key AVP> {<Public-Key-Security-Association AVP> XOR <Secret-Key-Security-Association AVP>} <Transform AVP> <Auth-Method AVP> <SA-Life-Seconds AVP> <SA-Life-Kbs AVP> <SA-Source AVP> <Anti-Replay AVP> <Host-IP-Address AVP> [<Nonce AVP>] <Timestamp AVP> {<Message-Authentication-Code AVP> OR <Digital-Signature AVP>} AVP Format The IPSec-SA-Setup Command AVP is shown below. The fields are transmitted from right to left. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | Reserved |P|T|V|E|H|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Code 256 DIAMETER-Command AVP Length The length of this AVP must be 12. AVP Flags The 'M' bit must be set. The 'P', 'T', 'V', 'E' and 'H' bits MUST NOT be set. Command Code The Command Code field must be set to N+2 (IPSec-SA-Setup). Ladley Expires 23 December 1999 [Page 22] INTERNET DRAFT 23 June 1999 5.0 DIAMETER AVPs This section defines the AVPs which MUST be supported by all DIAMETER implementations supporting this extension. The following AVPs ar defined in this document: Attribute Name Attribute Code ------------------------------------------------------ Message-Authentication-Code M Network-Access-Identifier M+1 Sequence-Number M+2 Home-AAA-IP-Address M+3 Router-IP-Address M+4 Public-Key-Security-Association M+5 Secret-Key-Security-Association M+6 Session-Key M+7 SA-Source AVP M+8 5.1 Message-Authentication-Code Description The Message-Authentication-Code AVP contains a MAC of a bit sequence. A DIAMETER command which uses the Message-Authentication-Code AVP MUST define the sequence over which the MAC is computed. AVP Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | Reserved |P|T|V|E|H|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Shared Secret ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Authentication Code ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Code M AVP Length Ladley Expires 23 December 1999 [Page 23] INTERNET DRAFT 23 June 1999 The length of this AVP MUST be 32 if MD5 is used and 36 if SHA-1 is used. Reserved This field MUST be set to zero. AVP Flags The 'M' bit MUST be set. The 'H' and 'E' bits MAY be set. The 'V' and 'T' bits MUST NOT be set. The 'P' bit MAY be set. Algorithm ID This field is of type Integer32 and contains a value that identifies the algorithm that was used to compute the MAC. The following values are defined in this document: HMAC-MD5 1 [9][10] HMAC-SHA-1 2 [10][11] Keyed MD5 in "prefix+suffix" mode 3 [3] Shared Secret ID This field is of type Integer32 and contains an identifier of the shared secret that was used in the generation of the MAC using the transform identified by the 'Algorithm ID' field. The binding between this identifier and the secret MUST be established at the receiver before this AVP is received. This document does not specify any means of establishing such a binding. Message Authentication Code This field is of type Data and contains a MAC over some bit sequence, computed using the transform identified by the value of the 'Transform ID' field with the secret key identified by the value of the 'Secret Key ID' field. 5.2 Network-Access-Identifier Description This AVP contains an identifier of the user, encoded as a Network Access Identifier (NAI). Ladley Expires 23 December 1999 [Page 24] INTERNET DRAFT 23 June 1999 AVP Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | Reserved |P|T|V|E|H|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Access Identifier ... +-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+- AVP Code M+1 AVP Length The length of this AVP MUST be at least 9. Reserved This field MUST be set to zero. AVP Flags The 'M' bit MUST be set. The 'H' and 'E' bits MAY be set. The 'V' and 'T' bits MUST NOT be set. The 'P' bit MAY be set. Network Access Identifier This field is of type String and contains a Network Access Identifier as defined in [6]. 5.3 Sequence-Number Description This AVP contains a sequence number which is used for replay protection as described in 3.6. Ladley Expires 23 December 1999 [Page 25] INTERNET DRAFT 23 June 1999 AVP Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | Reserved |P|T|V|E|H|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Code M+3 AVP Length The length of this AVP must be 12. Reserved This field MUST be set to zero. AVP Flags The 'M' bit MUST be set. The 'H' and 'E' bits MAY be set. The 'V' and 'T' bits MUST NOT be set. The 'P' bit MAY be set. Sequence Number This AVP is of type Integer32 and contains a sequence number which is used for replay protection as described in 3.6. 5.4 Home-AAA-IP-Address Description This AVP contains an IP address of a home AAA server. Ladley Expires 23 December 1999 [Page 26] INTERNET DRAFT 23 June 1999 AVP Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | Reserved |P|T|V|E|H|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home AAA IP Address | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Code M+4 AVP Length The length of this AVP MUST be either 12 or 24. Reserved This field MUST be set to zero. AVP Flags The 'M' bit MUST be set. The 'H' and 'E' bits MAY be set. The 'V' and 'T' bits MUST NOT be set. The 'P' bit MAY be set. Home AAA IP Address This field is of type Address and contains an IP address of a home AAA server. 5.5 Router-IP-Address Description This AVP contains an IP address of a user node's first-hop router. Ladley Expires 23 December 1999 [Page 27] INTERNET DRAFT 23 June 1999 AVP Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | Reserved |P|T|V|E|H|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Address | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Code M+5 AVP Length The length of this AVP MUST be either 12 or 24. Reserved This field MUST be set to zero. AVP Flags The 'M' bit MUST be set. The 'H' and 'E' bits MAY be set. The 'V' and 'T' bits MUST NOT be set. The 'P' bit MAY be set. Router Address This field is of type Address and contains an IP address of a user node's first-hop router. 5.6 Public-Key-Security-Association Description The Public-Key-Security-Association contains three pieces of information: an index of an AVP, a public key and an identifier of a cryptographic algorithm. It is used in a message which contains an AVP which has been encrypted with a public key to inform the receiver of the algorithm and public key used for encryption, so that the receiver can decrypt the AVP with the corresponding private key. Ladley Expires 23 December 1999 [Page 28] INTERNET DRAFT 23 June 1999 AVP Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | Reserved |P|T|V|E|H|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target AVP Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Public Key ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Code M+6 AVP Length The length of this AVP MUST be between 80 and 272 (corresponding to the minimum and maximum RSA key lengths). Reserved This field MUST be set to zero. AVP Flags The 'M' bit MUST be set. The 'H' and 'E' bits MAY be set. The 'V' and 'T' bits MUST NOT be set. The 'P' bit MAY be set. Target AVP Index This field is of type Integer32 and identifies the encrypted AVP within the DIAMETER message containing the Public-Key-Security-Association AVP. The AVPs in the DIAMETER message are numbered starting from zero. The Command AVP, of which every DIAMETER message has one and only one, has an index of zero. Algorithm ID This field is of type Integer32 and contains a value that identifies the algorithm that was used to encrypt the AVP. The following values are defined in this document: RSA 1 [14] Ladley Expires 23 December 1999 [Page 29] INTERNET DRAFT 23 June 1999 Public Key This field is of type Data and contains the public key that was used to encrypt the AVP identified by the AVP Index using the algorithm identified by the Algorithm ID. 5.7 Secret-Key-Security-Association Description The Secret-Key-Security-Association contains a security parameters index which identifies a security association shared between two entities. It is used in a message which contains an AVP which has been encrypted with a secret key to inform the receiver of the algorithm, mode, key and any other necessary parameters used for encryption so that the receiver can decrypt the AVP. AVP Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | Reserved |P|T|V|E|H|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target AVP Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Code M+7 AVP Length The length of this AVP MUST be 16. Reserved This field MUST be set to zero. AVP Flags The 'M' bit MUST be set. The 'H' and 'E' bits MAY be set. The 'V' and 'T' bits MUST NOT be set. The 'P' bit MAY be set. Ladley Expires 23 December 1999 [Page 30] INTERNET DRAFT 23 June 1999 Target AVP Index This field is of type Integer32 and identifies the encrypted AVP within the DIAMETER message containing the Secret-Key-Security-Association AVP. The AVPs in the DIAMETER message are numbered starting from zero. The Command AVP, of which every DIAMETER message has one and only one, has an index of zero. 5.8 Session-Key Description This AVP contains a randomly chosen key of at least 128 bits which is used for authentication of IP datagrams from the user node. AVP Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | Reserved |P|T|V|E|H|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Key ... +-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+- AVP Code M+8 AVP Length The length of this AVP MUST be at least 24. Reserved This field MUST be set to zero. AVP Flags The 'M' bit MUST be set. Either the 'H' bit or the 'E' bit MUST be set. The 'V' and 'T' bits MUST NOT be set. The 'P' bit MAY be set. Session Key This field is of type Data and contains a randomly chosen key of Ladley Expires 23 December 1999 [Page 31] INTERNET DRAFT 23 June 1999 at least 128 bits which is used for authentication of IP datagrams from the user node. 5.9 SA-Source This AVP contains the IP address which will be the source of an IPSec security association. The format of the header of this AVP differs from the header format defined in [1]; see [8] for more information. 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 M+9 Length The length of this AVP MUST be either 12 or 24. 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 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. Ladley Expires 23 December 1999 [Page 32] INTERNET DRAFT 23 June 1999 Value The value field contains the address of the IPSec source, which may be the target user node or an intervening security gateway. 6.0 Security considerations The usual considerations with regard to picking random numbers [15] apply to the generation of the session key Kc. This protocol is only as secure as the least secure of the mechanisms used to establish and keep secret any secret keys used, such as Ka, Ki, Kc and Kr. It is also dependent on a home AAA server having secure access to a high-quality random number generator for session key generation. Public keys MUST NOT be used for either encryption or signature verification without establishing confidence in the authenticity of the key. This will probably be done by the use of public key certificates. It should be borne in mind that public key certificates may expire or be revoked; certificate revocation lists may be used to check the revocation status of certificates. Because Timestamp AVPs [1] are added by the DIAMETER Proxy Server Extension, it is necessary that all nodes have adequately synchronized clocks. Compromise of a node's clock may render the protocol vulnerable to replay attacks. 7.0 Performance considerations This protocol introduces a certain overhead in the form of the time and message passing required to perform authentication. It also introduces a per-packet overhead because of the necessity to generate an IPSec Authentication Header in the user node, transmit it and verify it in the user node's first-hop router. 8.0 References [1] Calhoun, Rubens, DIAMETER Base Protocol. Internet-Draft, draft-calhoun-diameter-08.txt, November 1998. Work in progress. [2] Stephen Kent and Randall Atkinson. IP Authentication Header. RFC 2402, November 1998. [3] Charles Perkins, editor. IP Mobility Support. RFC 2002, October 1996. Ladley Expires 23 December 1999 [Page 33] INTERNET DRAFT 23 June 1999 [4] David B. Johnson and Charles Perkins. Mobility Support In IPv6. Internet-Draft, draft-ietf-mobileip-ipv6-07.txt, November 1998. Work in progress. [5] Scott Bradner. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119, March 1997. [6] Bernard Aboba and Mark A. Beadles. The Network Access Identifier. RFC 2486, January 1999. [7] Stephen Kent and Randall Atkinson. Security Architecture for the Internet Protocol. RFC 2401, November 1998. [8] Sumit Vakil and Pat Calhoun. DIAMETER IP Security Policy Extensions. Internet-Draft, draft-calhoun-diameter-ipsec-policy-00.txt, March 1998. Work in progress. [9] Ronald Rivest. The MD5 Digest Algorithm. RFC 1321, April 1992. [10] Krawczyk, H., Bellare, M., and Canetti, R. HMAC: Keyed-Hashing for Message Authentication. RFC 2104, February 1997. [11] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995. http://csrc.nist.gov/fips/fip180-1.txt (ascii) http://csrc.nist.gov/fips/fip180-1.ps (postscript) [12] Calhoun, Rubens. DIAMETER Reliable Transport Extensions. Internet-Draft, draft-calhoun-diameter-reliable-01.txt. February 1999. Work in progress. [13] Pat Calhoun and William Bulley. DIAMETER Proxy Server Extensions. Internet-Draft, draft-calhoun-diameter-proxy-01.txt, August 1998. Work in progress. [14] Rivest, R., Shamir, A., and Adleman, L., "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems", Communications of the ACM, v. 21, n. 2, February 1978. [15] Eastlake, D., Crocker, S. and Schiller, J. Randomness Recommendations for Security. RFC 1750, December 1994 . [16] Lars Westberg and Morgan Lindqvist. Realtime Traffic over Cellular Access Networks. Internet-Draft, draft-westberg-realtime-cellular-00.txt. June 1999. Ladley Expires 23 December 1999 [Page 34] INTERNET DRAFT 23 June 1999 9.0 Acknowledgements The author wishes to thank Christian Gehrmann, Anders Herlitz, Yuri Ismailov, Annika Jonsson and Hesham Soliman at Ericsson for help with this draft and interesting discussions. 10.0 Author's Address Questions about this Internet-Draft can be directed to: Fergal Ladley Ericsson Radio Systems AB Kistagangen 26 SE-16480 Stockholm Sweden Phone: +46 8 404 8534 Fax: +46 8 757 3100 e-mail: erafela@era-t.ericsson.se Ladley Expires 23 December 1999 [Page 35] INTERNET DRAFT 23 June 1999