INTERNET-DRAFT Fergal Ladley
expires on 23 December 1999 Ericsson
23 June 1999
A DIAMETER-based Authentication and Access Control Protocol
<draft-ladley-diameter-pr-00.txt>
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:
[<Access-Request Command AVP><Session-Id AVP><plaintext
Network-Access-Identifier AVP><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