One document matched: draft-ietf-hokey-erx-09.txt
Differences from draft-ietf-hokey-erx-08.txt
Network Working Group V. Narayanan
Internet-Draft L. Dondeti
Intended status: Standards Track Qualcomm, Inc.
Expires: August 7, 2008 February 4, 2008
EAP Extensions for EAP Re-authentication Protocol (ERP)
draft-ietf-hokey-erx-09
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on August 7, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
The extensible authentication protocol (EAP) is a generic framework
supporting multiple types of authentication methods. In systems
where EAP is used for authentication, it is desirable to not repeat
the entire EAP exchange with another authenticator. This document
specifies extensions to EAP and EAP keying hierarchy to support an
EAP method-independent protocol for efficient re-authentication
between the peer and the server through an authenticator.
Narayanan & Dondeti Expires August 7, 2008 [Page 1]
Internet-Draft ERP February 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. ERP Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. ERP With the Home ER Server . . . . . . . . . . . . . . . 5
3.2. ERP with a Local ER Server . . . . . . . . . . . . . . . . 7
4. ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Key Derivations and Properties . . . . . . . . . . . . . . 10
4.1.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . 10
4.1.2. rRK Properties . . . . . . . . . . . . . . . . . . . . 10
4.1.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . 11
4.1.4. rIK Properties . . . . . . . . . . . . . . . . . . . . 12
4.1.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . 12
4.1.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . 13
4.1.7. rMSK Properties . . . . . . . . . . . . . . . . . . . 13
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 14
5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 14
5.1.1. ERP Bootstrapping with a Local ER Server . . . . . . . 17
5.2. EAP Re-auth Protocol . . . . . . . . . . . . . . . . . . . 18
5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 20
5.2.2. Failure Handling . . . . . . . . . . . . . . . . . . . 20
5.3. New EAP Messages . . . . . . . . . . . . . . . . . . . . . 21
5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 22
5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 23
5.3.3. EAP Finish/Re-auth Packet . . . . . . . . . . . . . . 26
5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 29
5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 30
5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 31
6. Transport of ERP Messages . . . . . . . . . . . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.1. Normative References . . . . . . . . . . . . . . . . . . . 37
10.2. Informative References . . . . . . . . . . . . . . . . . . 38
Appendix A. Example ERP Exchange . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . . . . 41
Narayanan & Dondeti Expires August 7, 2008 [Page 2]
Internet-Draft ERP February 2008
1. Introduction
The extensible authentication protocol (EAP) is a generic framework
for transport of methods that authenticate two parties; the
authentication is either one-way or mutual. The primary purpose is
network access control, and a key-generating method is recommended to
enforce access control. The EAP keying hierarchy defines two keys
that are derived at the top level: the Master Session Key (MSK) and
the Extended MSK (EMSK). In the most common deployment scenario, a
peer and a server authenticate each other through a third party known
as the authenticator. The authenticator or an entity controlled by
the authenticator enforces access control. After successful
authentication, the server transports the MSK to the authenticator;
the authenticator and the peer derive transient session keys (TSK)
using the MSK as the authentication key or a key derivation key and
use the TSK for per-packet access enforcement.
When a peer moves from one authenticator to another, it is desirable
to avoid a full EAP authentication. The full EAP exchange with
another run of the EAP method can take several round trips and
significant time to complete, causing delays in handover times. Some
EAP methods specify the use of state from the initial authentication
to optimize re-authentications by reducing the computational
overhead, but method-specific re-authentication takes at least 2
round trips in most cases (e.g., [6]). It is also important to note
that many methods do not offer support for re-authentication. Thus,
it is beneficial to have efficient re-authentication support in EAP
rather than in individual methods.
Key sharing across authenticators is sometimes used as a practical
solution to lower handover times. In that case, compromise of an
authenticator results in compromise of keying material established
via other authenticators.
Other solutions for fast re-authentication exist in the literature
[7] [8].
In conclusion, there is a need to design an efficient EAP re-
authentication mechanism that allows a fresh key to be established
between the peer and an authenticator without having to execute the
EAP method again. The EAP re-authentication problem statement is
described in detail in [9].
This document specifies EAP Re-authentication Extensions (ERX) for
efficient re-authentication using EAP. The protocol that uses these
extensions itself is referred to as the EAP re-authentication
Protocol (ERP). It supports EAP method independent re-authentication
for a peer that has valid, unexpired key material from a previously
Narayanan & Dondeti Expires August 7, 2008 [Page 3]
Internet-Draft ERP February 2008
performed EAP authentication. The protocol and the key hierarchy
required for EAP re-authentication is described in this document.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
This document uses the basic EAP terminology [2] and EMSK keying
hierarchy terminology [3]. In addition, this document uses the
following terms:
ER peer - An EAP peer that supports the EAP re-authentication
protocol. All references to "peer" in this document imply an ER
peer, unless specifically noted otherwise.
ER Authenticator - An entity that supports the authenticator
functionality for EAP re-authentication described in this
document. All references to "authenticator" in this document
imply an ER authenticator, unless specifically noted otherwise.
ER Server - An entity that performs the server portion of ERP
described here. This entity may or may not be an EAP server. All
references to "server" in this document imply an ER server, unless
specifically noted otherwise.
ERX: EAP re-authentication extensions.
ERP: EAP re-authentication Protocol that uses the re-
authentication extensions.
rRK - re-authentication root Key, derived from the EMSK or DSRK.
rIK - re-authentication Integrity Key, derived from the rRK.
rMSK - re-authentication MSK. This is a per-authenticator key,
derived from the rRK.
Domain - Refers to a "key management domain" as defined in [3].
For simplicity, it is referred to as "domain" in this document.
The terms "home domain" and "local domain" are used to
differentiate between the originating key management domain that
performs the full EAP exchange with the peer and the local domain
to which a peer may be attached to at a given time.
Narayanan & Dondeti Expires August 7, 2008 [Page 4]
Internet-Draft ERP February 2008
3. ERP Overview
Figure 2 shows the protocol exchange. The first time the peer
attaches to an authenticator, it performs a full EAP exchange (shown
in Figure 1) with the EAP server; as a result an MSK is distributed
to the authenticator. The MSK is then used by the authenticator and
the peer to generate TSKs as needed. At the time of the initial EAP
exchange, the peer and the server derive a re-authentication Root Key
(rRK). The rRK may be derived from the EMSK or from a Domain
Specific Root Key (DSRK). The rRK is only available to the peer and
the ER server and is never handed out to any other entity. Further,
a re-authentication Integrity Key (rIK) is derived from the rRK; the
peer uses the rIK to provide proof of possession while performing an
ERP exchange at a later time. The rIK is also never handed out to
any entity and is only available to the peer and server.
When the ER server is in the home domain, the peer and the server use
the rIK and rRK derived from the EMSK and when the ER server is not
in the home domain, they use the DS-rIK and DS-rRK corresponding to
the local domain. The realm in the rIKname-NAI or the Peer-ID
reflects the ER server's domain.
3.1. ERP With the Home ER Server
Peer Authenticator Server
==== ============= ======
<--- EAP-Request/ ------
Identity
----- EAP Response/ --->
Identity ---EAP Response/Identity-->
<------------ EAP Method exchange------------------->
<----MSK, EAP-Success------
<---EAP-Success---------
Figure 1: EAP Authentication
Narayanan & Dondeti Expires August 7, 2008 [Page 5]
Internet-Draft ERP February 2008
Peer Authenticator Server
==== ============= ======
[<-- EAP-Request/ ------
Identity]
[<-- EAP Initiate/ ------
Reauth-Start]
---- EAP Initiate/ ----> ----EAP Initiate/ ---------->
Re-auth/ Re-auth/
[Bootstrap] [Bootstrap]
<--- EAP Finish/ ------> <---rMSK,EAP Finish/---------
Re-auth/ Re-auth/
[Bootstrap] [Bootstrap]
Note: [] brackets indicate optionality.
Figure 2: ERP Exchange
When the peer subsequently identifies a target authenticator that
supports EAP re-authentication, it performs an ERP exchange, as shown
in Figure 2 as well; the exchange itself may happen when the peer
attaches to a new authenticator supporting EAP re-authentication, or
prior to attachment. The peer initiates ERP by itself; it may also
do so in response to an EAP-Request/Identity or EAP-Initiate/
Re-auth-Start message from the new authenticator. The EAP-Initiate/
Re-auth-Start message allows the authenticator to initiate the ERP
exchange. It is plausible that the authenticator does not know
whether the peer supports ERP and whether it has performed a full EAP
authentication through another authenticator and hence the
authenticator initiation of the ERP exchange may require the
authenticator to send both the EAP-Request/Identity and EAP-Initiate/
Re-auth-Start messages.
We introduce two new codes to EAP: EAP-Initiate and EAP-Finish. For
reauthentication, the peer sends an EAP-Initiate/Re-auth message that
includes the Peer-ID or a temporary NAI based on the rIKname, and a
sequence number for replay protection. The Peer-ID used here is the
same as that exported by the EAP method, when it is available. The
EAP-Initiate/Re-auth message is integrity protected with the rIK.
The message is routed using the NAI in the rIKname-NAI [4], field and
if that is not present, it is routed using the NAI in the Peer-ID.
The server uses the rIKname or the Peer-ID in that order to lookup
the rIK. The server, after verifying proof of possession of the rIK,
and freshness of the message, derives a re-authentication MSK (rMSK)
Narayanan & Dondeti Expires August 7, 2008 [Page 6]
Internet-Draft ERP February 2008
from the rRK using the sequence number as an input to the key
derivation.
In response to the EAP-Initiate/Re-auth message, the server sends an
EAP-Finish/Re-auth message; this message is integrity protected with
the rIK. The server transports the rMSK along with this message to
the authenticator. The rMSK is transported in a manner similar to
that of the MSK along with the EAP-Success message in a full EAP
exchange. Ongoing work in [10] describes an additional key
distribution protocol that can be used to transport the rRK from an
EAP server to one of many different ER servers that share a AAA trust
relationship with the EAP server.
In an ERP bootstrap exchange, the peer may request the rRK lifetime
to be sent to it. If so, the ER server sends the lifetime along with
the EAP-Finish/Re-auth message.
The peer verifies the replay protection and the origin of the
message. It then uses the sequence number in the EAP-Finish/Re-auth
message to compute the rMSK. The lower-layer security association
protocol is ready to be triggered after this point.
3.2. ERP with a Local ER Server
The defined ER extensions allow executing the ERP with an ER server
in the local domain (access network). The local ER server may be co-
located with a local AAA server. The peer may learn about the
presence of a local ER server in the network and the local domain (or
ER server) name either via the lower layer or by means of ERP
bootstrapping. Figure 3 shows the full EAP and subsequent local ERP
exchange with a local ER server.
Narayanan & Dondeti Expires August 7, 2008 [Page 7]
Internet-Draft ERP February 2008
Peer Authenticator Local Server Home Server
==== ============= ============ ===========
<-- EAP-Request/ -----
Identity
--- EAP Response/ --->
Identity --EAP Response/-->
Identity --EAP Response/Identity->
[DSRK Req, Domain Identity]
<------------------------ EAP Method exchange------------------->
<---MSK, DSRK, EAP-Success--
<---MSK, EAP-Success--
<---EAP-Success---
Peer Authenticator Local Server
==== ============= ============
[<-- EAP-Request/ ------
Identity]
[<-- EAP Initiate/ ------
Re-auth-Start]
---- EAP Initiate/ ----> ----EAP Initiate/ ---------->
Re-auth/ Re-auth/
<--- EAP Finish/ ------ <---rMSK,EAP Finish/---------
Re-auth/ Re-auth/
Figure 3: Local ERP Exchange
As shown in Figure 3, the local ER server may be present in the path
of the full EAP exchange (e.g., this may be one of the AAA entities,
such as AAA proxies, in the path between the authenticator and the
home EAP server of the peer). In that case, at the end of a full
authentication exchange, the DSRK may be provided to the local ER
server. Alternatively, the DSRK can be obtained at the time of an
ERP bootstrap exchange with the home server. The DSRK is computed as
specified in [3]. The local ER server then computes a DS-rRK and a
Narayanan & Dondeti Expires August 7, 2008 [Page 8]
Internet-Draft ERP February 2008
DS-rIK (and the appropriate key names) from the DSRK as defined in
Section 4.1.1 and Section 4.1.3 below. The peer also derives the
DSRK, followed by the DS-rRK and the DS-rIK (and the appropriate key
names) following the EAP or ERP bootstrap exchange.
Subsequently, when the peer attaches to an authenticator within the
local domain, it may perform an ERP exchange with the local ER server
to obtain an rMSK for the new authenticator.
4. ER Key Hierarchy
Each time the peer reauthenticates to the network, the peer and the
authenticator establish an rMSK. The rMSK serves the same purposes
that an MSK, which is the result of full EAP authentication, serves.
To prove possession of the rRK, we specify the derivation of another
key, the rIK. These keys are derived from the rRK. Together they
constitute the ER key hierarchy.
The rRK is derived from either the EMSK or a DSRK as specified in
this document. For the purpose of rRK derivation, this document
specifies derivation of a Usage Specific Root Key (USRK) or a Domain
Specific USRK (DS-USRK) in accordance with [3] for re-authentication.
The USRK designated for re-authentication is the re-authentication
root key (rRK). A DS-USRK designated for re-authentication is the
DS-rRK available to a local ER server in a particular domain. For
simplicity, the keys are referred to without the DS label in the rest
of the document. However, the scope of the various keys is limited
to just the respective domains they are derived for, in the case of
the domain specific keys. Based on the ER server with which the peer
performs the ERP exchange, it knows the corresponding keys that must
be used.
The rRK is used to derive a rIK, and rMSKs for one or more
authenticators. The figure below shows the key hierarchy with the
rRK, rIK and rMSKs.
rRK
|
+--------+--------+
| | |
rIK rMSK1 ...rMSKn
Figure 4: Re-authentication Key Hierarchy
Narayanan & Dondeti Expires August 7, 2008 [Page 9]
Internet-Draft ERP February 2008
4.1. Key Derivations and Properties
The derivations in this document are according to [3]. Key
derivations, field encodings, where unspecified, default to that
document.
4.1.1. rRK Derivation
The rRK may be derived from the EMSK or DSRK. This section provides
the relevant key derivations for that purpose.
The rRK is derived as specified in [3].
rRK = prf+ (K, S), where,
K = EMSK or K = DSRK and
S = rRK Label + "\0" + NULL + length
The rRK Label is an IANA-assigned 8-bit ASCII string "EAP Re-
authentication Root Key@ietf.org" assigned from the Key Label name
space in accordance with [3]. This document specifies IANA
registration for the rRK label above.
The prf+ operation is as defined in [3].
Along with the rRK, a unique rRK name is derived to identify the rRK.
The rRKname is derived as follows.
rRKname = SHA-256-64 (NameDerivationKey, rRK Label)
where the SHA-256-64 operation is as defined in [3].
NameDerivationKey = EAP Session-ID, when K used in rRK derivation is
the EMSK,
NameDerivationKey = DSRK Name, when K used in rRK derivation is the
DSRK.
An rRK derived from the DSRK is referred to as a DS-rRK in the rest
of the document. All the key derivation and properties specified in
this section remain the same.
4.1.2. rRK Properties
The rRK has the following properties. These properties apply to the
rRK regardless of the parent key used to derive it.
Narayanan & Dondeti Expires August 7, 2008 [Page 10]
Internet-Draft ERP February 2008
o The length of the rRK MUST be equal to the length of the parent
key used to derive it.
o The rRK is to be used only as a root key for re-authentication and
never used to directly protect any data.
o The rRK is only used for derivation of rIK and rMSK as specified
in this document.
o The rRK MUST remain on the peer and the server that derived it and
MUST NOT be transported to any other entity.
o The lifetime of the rRK is never greater than that of its parent
key. The rRK is expired when the parent key expires and MUST be
removed from use at that time.
4.1.3. rIK Derivation
The re-authentication Integrity Key (rIK) is used for integrity
protecting the ERP exchange. This serves as the proof of possession
of valid keying material from a previous full EAP exchange by the
peer to the server.
The rIK is derived as follows.
rIK = prf+ (K, S ) where,
K = rRK and
S = rIK Label + "\0" + cryptosuite + length
The rIK Label is the 8-bit ASCII string "Re-authentication Integrity
Key@ietf.org" and the length refers to the length of the rIK in
octets.
The PRF used MAY be the same as that used by the EAP method - using
the PRF from the EAP method provides algorithm agility. Otherwise,
the default PRF used is HMAC-SHA256. The PRF is specified as part of
the ERP message exchange.
The cryptosuite and length of the rIK are part of the input to the
key derivation function to ensure cryptographic separation of keys if
different rIKs of different lengths for use with different MAC
algorithms are derived from the same rRK. The cryptosuite is encoded
as an 8-bit number: See Section 5.3.2 for cryptosuite specification.
The rIKname is derived as follows.
Narayanan & Dondeti Expires August 7, 2008 [Page 11]
Internet-Draft ERP February 2008
rIKname = SHA256-64(rRKname, rIK Label)
An rIK derived from a DS-rRK is referred to as a DS-rIK in the rest
of the document. All the key derivation and properties specified in
this section remain the same.
4.1.4. rIK Properties
The rIK has the following properties.
o The length of the rIK MUST be equal to the length of the rRK.
o The rIK is only used for authentication of the ERP exchange as
specified in this document.
o The rIK MUST NOT be used to derive any other keys.
o The rIK must remain on the peer and the server and MUST NOT be
transported to any other entity.
o The rIK is cryptographically separate from any other keys derived
from the rRK.
o The lifetime of the rIK is never greater than that of its parent
key. The rIK MUST be expired when the EMSK expires and MUST be
removed from use at that time.
4.1.5. rIK Usage
The rIK is the key whose possession is demonstrated by the peer and
the ERP server to the other party. The peer demonstrates possession
of the rIK by computing the integrity checksum over the EAP-Initiate/
Re-auth message. When the peer uses the rIK for the first time, it
can choose the integrity algorithm to use with the rIK. The peer and
the server MUST use the same integrity algorithm with a given rIK for
all ERP messages protected with that key. The peer and the server
store the algorithm information after the first use and the same
algorithm for all subsequent uses of that rIK.
If the server's policy does not allow the use of the cryptosuite
selected by the peer, the server may reject the EAP-Initiate/Re-auth
message and send a list of acceptable cryptosuites in the EAP-Finish/
Re-auth message.
The rIK length may be different from the key length required by an
integrity algorithm. In case of hash-based MAC algorithms, the key
is first hashed to the required key length as specified in [5]. In
case of cipher-based MAC algorithms, if the required key length is
Narayanan & Dondeti Expires August 7, 2008 [Page 12]
Internet-Draft ERP February 2008
less than 32 octets, the rIK is hashed using HMAC-SHA256 and the most
significant k octets of the output are used where k is the key length
required by the algorithm. If the required key length is more than
32 octets, the most significant k octets of the rIK are used by the
cipher-based MAC algorithm.
4.1.6. rMSK Derivation
The rMSK is derived at the peer and server and delivered to the
authenticator. The rMSK is derived following an EAP Re-auth protocol
exchange.
The rMSK is derived as follows.
rMSK = prf+ (K, S ) where,
K = rRK and
S = rMSK label + "\0" + SEQ + length
The rMSK label is the 8-bit ASCII string "Re-authentication Master
Session Key@ietf.org" and the length refers to the length of the rMSK
in octets.
SEQ is the sequence number sent by the peer in the EAP-Initiate/
Re-auth message. This field is encoded as a 16-bit number in the
network byte order (see Section 5.3.2).
The PRF is specified as part of the ERP message exchange. The
default PRF used is HMAC-SHA256.
The rMSK name is derived as follows:
rMSK_name = HMAC-SHA256-64 (rMSK, "rMSK Name")
An rMSK derived from a DS-rRK is referred to as a DS-rIK in the rest
of the document. All the key derivation and properties specified in
this section remain the same.
4.1.7. rMSK Properties
The rMSK has the following properties:
o The length of the rMSK MUST be equal to the length of the rRK.
o The rMSK is delivered to the authenticator and is used for the
same purposes that an MSK is used at an authenticator.
Narayanan & Dondeti Expires August 7, 2008 [Page 13]
Internet-Draft ERP February 2008
o The rMSK is cryptographically separate from any other keys derived
from the rRK.
o The lifetime of the rMSK is less than or equal to that of the rRK.
It MUST NOT be greater than the lifetime of the rRK.
o If a new rRK is derived, subsequent rMSKs MUST be derived from the
new rRK. Previously delivered rMSKs MAY still be used until the
expiry of the lifetime.
o A given rMSK MUST NOT be shared by multiple authenticators.
5. Protocol Description
ERP allows a peer and server to verify proof of possession of keying
material from an earlier EAP method run and establish a security
association between the peer and an authenticator. The authenticator
acts as a pass-through entity for the Re-auth protocol in a manner
similar to that described in RFC 3748 [2]. ERP is a single round-
trip exchange between the peer and the server; it is independent of
the lower layer and the EAP method used during the full EAP exchange.
5.1. ERP Bootstrapping
When the peer requires the local domain identity to use ERP in the
local domain, or when it moves to a new domain and needs to have a
new DSRK delivered to the local ER server and wants to obtain the
domain identity for domain-specific key derivation, it can use the
bootstrapping process with the home domain ER server.
We identify two types of bootstrapping for ERP: explicit and implicit
bootstrapping. In implicit bootstrapping, the domain specific keys
are delivered to the local ER server during the EAP exchange. The
peer learns the domain identity through out-of-band means. When the
domain identity is available to the peer during or after the full EAP
authentication, it attempts to use ERP when it associates with a new
authenticator.
For explicit bootstrapping, the peer initiates the EAP Re-auth
exchange with the bootstrapping flag turned on immediately after the
full EAP authentication finishes. The following steps summarize the
process:
o The peer sends the EAP-Initiate/Re-auth message with the
bootstrapping flag turned on. It is RECOMMENDED that the
authenticator hold on to the state (e.g., called station id in
RADIUS) that allows all messages of a full EAP conversation to be
Narayanan & Dondeti Expires August 7, 2008 [Page 14]
Internet-Draft ERP February 2008
routed to the same server. The EAP-Initiate/Re-auth message
contains one or more TLVs containing identification information to
assist the authenticator further in sending the message to the
appropriate ER server -- in this case to the ER server that holds
the EMSK, rRK, and rIK.
* It is mandatory to send the rIKname either by itself, or as
part of an NAI (see Section 5.3.2). The authenticator may use
the NAI to route the EAP-Initiate/Re-auth Bootstrap message.
* When rIKname-NAI is not available, the Peer-ID SHOULD be
included. The Peer-ID may be in the form of a pseudonym for
identity privacy.
* If an NAI is not available as part of the peer-name or the
rIKname, an authenticator routes the ERP packets to the default
ER server in the network. The default ER server may be the
authenticator itself. When neither an NAI nor a default ER
server are available to an authenticator, it drops the ERP
packets silently.
o In addition to the identities, the message contains a sequence
number for replay protection, a cryptosuite, and an integrity
checksum. The cryptosuite indicates the authentication algorithm
and the PRF. The integrity checksum indicates that the message
originated at the claimed entity, the peer indicated by the
Peer-ID, or the rIKname.
o The peer may additionally set the lifetime flag to request that
the rRK lifetime be sent to it.
o When an ERP-capable authenticator receives EAP-Initiate/Re-auth
message from a peer, it looks for local EAP forwarding state
corresponding to the peer's lower-layer address and forwards the
message accordingly. This forwarding is similar to that of
messages of an EAP conversation. It is RECOMMENDED that an ERP-
capable authenticator store that forwarding information for a
finite amount of time after the EAP-Success message has been sent
to the peer.
* In the absence of forwarding state, the authenticator parses
the EAP-Initiate/Re-auth message to locate the rIKname, and if
the rIKname is in the NAI form, uses that domain identity to
forward the message.
* Otherwise, it finds the Peer-ID and uses the realm portion of
the Peer-ID to route the EAP message to the appropriate server.
Narayanan & Dondeti Expires August 7, 2008 [Page 15]
Internet-Draft ERP February 2008
* In the absence of an NAI, the authenticator routes packets to
the default ER server in the local domain. If no such
information is available, the authenticator silently drops the
packets.
o Upon receipt of an EAP-Initiate/Re-auth message, the server
verifies whether the message is fresh or a replay by evaluating
whether the received sequence number is equal to or greater than
the expected sequence number for that rIK. The server then
verifies to ensure that the cryptosuite used by the peer is
acceptable. Next, it verifies the origin authentication of the
message by looking up the rIK. If any of the checks fail, the
server sends an EAP-Finish/Re-auth message with the Result flag
set to '1'. Please refer to Section 5.2.2 for details on failure
handling. This error MUST NOT have any correlation to any EAP-
Success message that may have been received by the authenticator
and the peer earlier. If the EAP-Initiate/Re-auth message is
well-formed and valid, the server prepares the EAP-Finish/Re-auth
message. The bootstrap flag is set to indicate that this is a
bootstrapping exchange. The message contains the following
fields:
* A sequence number for replay protection.
* The rIKname so that the peer can correctly identify the rIK to
verify the integrity and origin authentication of the EAP-
Finish/Re-auth message.
* If the lifetime flag was set in the EAP-Initiate/Re-auth
message, the ER server SHOULD include the rRK lifetime in the
EAP-Finish/Re-auth message. The server may have a local policy
to maintain and enforce lifetime unilaterally. In such cases,
the server need not respond to the peer's request for the
lifetime.
* An authentication tag to prove that the EAP-Finish/Re-auth
message originates at a server that possesses the rIK
corresponding to the rIKname.
o In addition, the rMSK is sent along with the EAP-Finish/Re-auth
message, in a AAA attribute [11].
Since the ER bootstrapping exchange is typically done immediately
following the full EAP exchange, it is feasible that the process is
completed through the same entity that served as the EAP
authenticator for the full EAP exchange. In this case, the lower
layer may already have derived the TSKs based on the MSK received
earlier. The lower layer may then choose to ignore the rMSK that was
Narayanan & Dondeti Expires August 7, 2008 [Page 16]
Internet-Draft ERP February 2008
received with the ER bootstrapping exchange. Alternatively, the
lower layer may choose to generate a TSK from the rMSK. However, the
bootstrapping exchange may be carried out via a new authenticator, in
which case, the rMSK received is used by the lower layer.
5.1.1. ERP Bootstrapping with a Local ER Server
When a local ER server is present, it may be in the path of the full
EAP exchange performed by the peer. In this case, the local ER
server SHOULD include a request for DSRK and its domain or server
name along with the AAA message encapsulating the first EAP Response
message sent by the peer. If the EAP exchange is successful, the
server sends a DSRK (for the local ER server) along with the EAP-
Success message. The local ER server MUST extract the DSRK, if
present, before forwarding the EAP-Success message to the peer, as
specified in [11] or [12]. Note that the MSK (also present along
with the EAP Success message) is still extracted by the authenticator
as usual.
If the peer performs an ERP bootstrapping exchange when a local ER
server is present, the local ER server MUST include the DSRK request
and its domain identity in the AAA message encapsulating the EAP-
Initiate/Re-auth message sent by the peer. If the exchange is
successful, the home ER server MUST include a DSRK along with the
EAP-Finish Re-auth message. The local ER server MUST extract the
DSRK, if present, before forwarding the EAP-Finish/Re-auth message to
the peer.
When the server receives an EAP-Initiate/Re-auth message with the
bootstrap flag set along with a DSRK request, it SHOULD return the
domain identity to which the DSRK was sent, in the EAP-Finish/Re-auth
message. The other processing rules for the ERP bootstrapping
exchange specified in Section 5.1 apply as well.
When the peer receives an EAP-Finish/Re-auth message with the
bootstrap flag set, if a local domain identity is present, it MUST
use that to derive the appropriate DSRK, DS-rRK and DS-rIK. If not,
the peer SHOULD derive the domain-specific keys using the domain
identity it learned via the lower layer. If the peer has no
available domain identity, it must assume that there is no local ER
server available.
The procedures for encapsulating ERP and obtaining relevant keys
using RADIUS and Diameter are specified in [11] and [12]
respectively.
Narayanan & Dondeti Expires August 7, 2008 [Page 17]
Internet-Draft ERP February 2008
5.2. EAP Re-auth Protocol
When a peer that has an active rRK and rIK associates with a new
authenticator that supports ERP, it may perform an ERP exchange with
that authenticator. ERP is typically a peer-initiated exchange,
consisting of an EAP-Initiate/Re-auth and an EAP-Finish/Re-auth
message. The ERP exchange may be performed with a local ER server
(when one is present) or with the original EAP server.
It is plausible for the network to trigger the EAP re-authentication
process however. When an ERP capable authenticator sends an EAP-
Request/Identity the peer may in response initiate the EAP re-
authentication exchange. Additionally, an ERP-capable authenticator
may also send an EAP-Initiate/Re-auth-Start message to indicate
support for ERP. The peer may or may not wait for these messages to
arrive to initiate the EAP-Initiate/Re-auth message.
The EAP-Initiate/Re-auth-Start message is sent by an ERP-capable
authenticator. The authenticator may retransmit it a few times until
it receives an EAP-Initiate/Re-auth message in response from the
peer. The EAP-Initiate/Re-auth message from the peer may have
originated before the peer receives either an EAP-Request/Identity or
an EAP-Initiate/Re-auth-Start message from the authenticator. Hence
the Identifier value in the EAP-Initiate/Re-auth message is
independent of the Identifier value in the EAP-Initiate/Re-auth Start
or the EAP-Request/Identity messages.
Operational Considerations at the Peer:
ERP requires that the peer maintain retransmission timers for
reliable transport of EAP re-authentication messages. The
reliability considerations of Section 4.3 of RFC 3748 apply with the
peer as the retransmitting entity.
The EAP Re-auth protocol has the following steps:
The peer sends an EAP-Initiate/Re-auth message including one or
more identity TLVs: the rIKname or rIKname-NAI, and optionally the
Peer-ID; also included are the peer's rIK sequence number, and a
cryptosuite indicating the cryptographic algorithms used. The
message is integrity protected with the rIK. When the peer is
performing ERP with a local ER server, it MUST use the
corresponding DS-rIK it shares with the local ER server. The peer
sets the lifetime flag to request the rRK lifetime from the
server. It may learn this to know when to trigger an EAP method
exchange.
Narayanan & Dondeti Expires August 7, 2008 [Page 18]
Internet-Draft ERP February 2008
If rIKname-NAI is present, the authenticator MUST use that NAI to
route the message. If the rIKname-NAI is not present, the
authenticator MUST use the NAI in the Peer-ID to forward the
message via AAA. If neither are available, the authenticator MUST
forward the ERP messages to the local ER server. If none of these
rules apply, the authenticator MUST drop the packets silently.
The server uses the rIKname to lookup the rIK. It first verifies
whether the sequence number is equal to or greater than the
expected sequence number. If the server supports sequence number
window size greater than 1, it verifies whether the sequence
number falls within the window and has not been received before.
The server then verifies to ensure that the cryptosuite used by
the peer is acceptable. The server then proceeds to verify the
integrity of the message using the rIK, thereby verifying proof of
possession of that key by the peer. If any of these verifications
fail, the server sends an EAP-Finish/Re-auth message with the
Result flag set to '1' (Failure). Please refer to Section 5.2.2
for details on failure handling. Otherwise, it computes an rMSK
from the rRK using the sequence number as the additional input to
the key derivation.
The server then sends an EAP-Finish/Re-auth message containing the
rIK sequence number and the rIKname. The sequence number MUST be
same as the received sequence number. The local copy of the
sequence number is incremented by 1. If the server supports
multiple simultaneous ERP exchanges, it updates the sequence
number window. The EAP-Finish/Re-auth message is also integrity
protected with the rIK. The server may include the server-id with
this message.
If the lifetime flag was set in the EAP-Initiate/Re-auth message,
the ER server SHOULD include the rRK lifetime in the EAP-Finish/
Re-auth message.
The server transports the rMSK along with this message to the
authenticator. The rMSK is transported in a manner similar to the
MSK transport along with the EAP-Success message in a regular EAP
exchange.
The peer looks up the sequence number to verify whether it is
expecting a EAP-Finish/Re-auth message with that sequence number.
It then looks up the rIKname and verifies the integrity of the
message. This also verifies the proof of possession of the rIK at
the server. If the verifications fail, the peer logs an error and
stops the process; otherwise, it proceeds to the next step.
Narayanan & Dondeti Expires August 7, 2008 [Page 19]
Internet-Draft ERP February 2008
The peer uses the sequence number to compute the rMSK.
The lower-layer security association protocol can be triggered at
this point.
5.2.1. Multiple Simultaneous Runs of ERP
When a peer is within the range of multiple authenticators, it may
choose to run ERP via all of them simultaneously to the same ER
server. In that case, it is plausible that the ERP messages may
arrive out of order, resulting in the ER server rejecting legitimate
EAP-Initiate/Re-auth messages.
To facilitate such operation, an ER server MAY allow multiple
simultaneous ERP exchanges by accepting all EAP-Initiate/Re-auth
messages with SEQ number values within a window of allowed values.
Recall that the SEQ number allows replay protection. Replay window
maintenance mechanisms are a local matter.
5.2.2. Failure Handling
If the processing of the EAP-Initiate/Re-auth message results in a
failure, the ER server MUST send an EAP Finish Re-auth message with
the Result flag set to '1'. If the server has a valid rIK for the
peer, it MUST integrity protect the EAP-Finish/Re-auth failure
message. If the failure is due to an unacceptable cryptosuite, the
server SHOULD send a list of acceptable cryptosuites (in a TLV of
Type 5) along with the EAP-Finish/Re-auth message. In this case, the
server MUST indicate the cryptosuite used to protect the EAP-Finish/
Re-auth message in the cryptosuite. The rIK used with the EAP-
Finish/Re-auth message in this case MUST be computed as specified in
Section 4.1.3 using the new cryptosuite. If the server does not have
a valid rIK for the peer, the EAP-Finish/Re-auth message indicating a
failure will be unauthenticated; the server MAY include a list of
acceptable cryptosuites in the message.
The peer, upon receiving an EAP-Finish/Re-auth message with the
Result flag set to '1', MUST verify the sequence number and the
Authentication Tag to determine the validity of the message. If the
peer supports the cryptosuite, it MUST verify the integrity of the
received EAP-Finish/Re-auth message. If the EAP-Finish message
contains a TLV of Type 5, the peer SHOULD retry the ERP exchange with
a cryptosuite picked from the list included by the server. The peer
MUST use the appropriate rIK for the subsequent ERP exchange, by
computing it with the corresponding cryptosuite, as specified in
Section 4.1.3. If the PRF in the chosen cryptosuite is different
from the PRF originally used by the peer, it MUST derive a new DSRK
(if required), rRK and rIK before proceeding with the subsequent ERP
Narayanan & Dondeti Expires August 7, 2008 [Page 20]
Internet-Draft ERP February 2008
exchange.
If the peer cannot verify the integrity of the received message, it
MAY choose to retry the ERP exchange with one of the cryptosuites in
the TLV of Type 5, after a failure has been clearly determined
following the procedure in the next paragraph.
If the replay or integrity checks fail, the failure message may have
been sent by an attacker. It may also imply that the server and peer
do not support the same cryptosuites; however, the peer cannot
determine if that is the case. Hence, the peer SHOULD continue the
ERP exchange per the retransmission timers before declaring a
failure.
5.3. New EAP Messages
Two new EAP Codes are defined for the purpose of ERP: EAP-Initiate
and EAP-Finish. The packet format for these messages follows the EAP
packet format defined in RFC3748 [2].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Type-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 5: EAP Packet
Code
5 Initiate
6 Finish
Two new code values are defined for the purpose of ERP. The
code values themselves are TBD based on IANA assignment.
Identifier
The Identifier field is one octet. The Identifier field MUST
be the same if an EAP-Initiate packet is retransmitted due to a
timeout while waiting for a Finish message. Any new (non-
retransmission) Initiate message MUST use a new Identifier
field.
Narayanan & Dondeti Expires August 7, 2008 [Page 21]
Internet-Draft ERP February 2008
The Identifier field of the Finish message MUST match that of
the currently outstanding Initiate message. A Peer or
Authenticator receiving a Finish message whose Identifier value
does not match that of the currently outstanding Initiate
message MUST silently discard the packet.
In order to avoid confusion between new EAP-Initiate messages
and retransmissions, the peer must choose a an Identifier value
that is different from the previous EAP-Initiate message,
especially if that exchange has not finished. It is
RECOMMENDED that the authenticator clear EAP Re-auth state
after 300 seconds.
Type
This field indicates that this is an ERP exchange. Two type
values are defined in this document for this purpose - Re-auth-
Start (assigned Type 1), Re-auth (assigned Type 2).
Type-Data
The Type-Data field varies with the Type of re-authentication
packet.
5.3.1. EAP-Initiate/Re-auth-Start Packet
The EAP-Initiate/Re-auth-Start packet contains the parameters shown
in Figure 6 :
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: EAP-Initiate/Re-auth-Start Packet
Type = 1.
Reserved, MUST be zero. Set to zero on transmission and ignored
on reception.
Narayanan & Dondeti Expires August 7, 2008 [Page 22]
Internet-Draft ERP February 2008
One or more TVs or TLVs are used to convey information to the
peer; for instance the authenticator may send domain identity to
the peer.
TVs or TLVs: In the TV payloads, there is a 1-octet type payload
and a value with type-specific length. In the TLV payloads, there
is a 1-octet type payload and a 1-octet length payload. The
length field indicates the length of the value expressed in number
of octets.
Domain-Identity: This is a TLV payload. The Type is 4. The
domain identity is to be used as the realm in an NAI [4].
5.3.1.1. Authenticator Operation
The authenticator optionally sends the EAP-Initiate/Re-auth-Start
message to indicate support for ERP to the peer and to initiate ERP
if the peer has already performed full EAP authentication and has
unexpired key material. The authenticator may include the domain
identity to allow the peer to learn it without lower-layer support or
the ERP bootstrapping exchange.
The authenticator may re-transmit the EAP-Initiate/Re-auth-Start
message a few times for reliable transport.
5.3.1.2. Peer Operation
The peer may send the EAP-Initiate/Re-auth message in response to the
EAP-Initiate/Re-auth-Start message from the authenticator. If the
peer does not recognize the Initiate code value, it silently discards
the message.
If the EAP-Initiate/Re-auth-Start message contains the domain
identity, and if the peer does not already have the domain
information, the peer uses the domain identity to compute the DSRK
and uses the corresponding DS-rIK to send an EAP-Initiate/Re-auth
message in response.
5.3.2. EAP-Initiate/Re-auth Packet
The EAP-Initiate/Re-auth packet contains the parameters shown in
Figure 7 :
Narayanan & Dondeti Expires August 7, 2008 [Page 23]
Internet-Draft ERP February 2008
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |R|B|L| Reserved| SEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: EAP-Initiate/Re-auth Packet
Type = 2.
Flags
'R' - The R flag is set to 0 and ignored upon reception.
'B' - The B flag is used as the bootstrapping flag. If the
flag is turned on, the message is a bootstrap message.
'L' - The L flag is used to request the rRK lifetime from the
server.
The rest of the 5 bits are set to 0 and ignored on reception.
SEQ: A 16-bit sequence number is used for replay protection. The
SEQ number field is initialized to zero every time a new rRK is
derived.
TVs or TLVs: In the TV payloads, there is a 1-octet type payload
and a value with type-specific length. In the TLV payloads, there
is a 1-octet type payload and a 1-octet length payload. The
length field indicates the length of the value expressed in number
of octets.
rIKname: This is carried in a TV payload. The Type is 1 and
the value is a 64-bit field computed as specified in Section
Section 4.1.3 and is used to identify the rIK with which the
ERP messages are protected.
Narayanan & Dondeti Expires August 7, 2008 [Page 24]
Internet-Draft ERP February 2008
rIKname-NAI: This is carried in a TLV payload. The Type is 2.
The NAI is variable in length, not exceeding 253 octets. The
rIKname is the username part of the NAI and is encoded in
hexadecimal values. If the rIK is derived from the EMSK, the
realm part of the NAI is the home domain identity and if the
rIK is derived from a DSRK, the realm part of the NAI is the
domain identity used in the derivation of the DSRK. The NAI
syntax follows [4].
Peer-ID: This is a TLV payload. The Type is 3. The Peer-ID is
the NAI of the peer, and is variable in length, not exceeding
253 octets.
In addition channel binding information may be included: see
Section 5.5 for additional discussion. See Figure 10 for
parameter specification. The peer sends this information seen
at the lower layer so that the server can verify the
information, if channel binding is to be supported.
Cryptosuite: This field indicates the integrity algorithm and the
PRF used for ERP. Key lengths and output lengths are either
indicated or are obvious from the cryptosuite name. We specify
some cryptosuites below, in the format Integrity-algorithm_PRF-
name:
* 0 RESERVED
* 1 HMAC-SHA256-64_HMAC-SHA256
* 2 HMAC-SHA256-128_HMAC-SHA256
* 3 HMAC-SHA256-256_HMAC-SHA256
HMAC-SHA256-128_HMAC-SHA256 is mandatory to support.
Authentication Tag: This field contains the integrity checksum
over the ERP packet, excluding the authentication tag field
itself. The length of the field is indicated by the Cryptosuite.
5.3.2.1. Peer Operation
When an ER capable peer receives an EAP-Request/Identity message from
an Authenticator, it checks to see if it has valid EAP state from a
previous EAP authentication. If the peer has state from a previous
authentication, and if it knows that the Authenticator is ER capable,
it sends an EAP-Initiate/Re-auth message instead of an EAP-Response/
Identity message. The peer may, upon attachment to an authenticator
send an EAP-Initiate/Re-auth message in an unsolicited manner.
Narayanan & Dondeti Expires August 7, 2008 [Page 25]
Internet-Draft ERP February 2008
5.3.2.2. Authenticator Operation
If the Authenticator does not recognize the EAP-Initiate Code, it
silently discards the EAP-Initiate/Re-auth message.
The Authenticator then parses the message to find the rIKname and
Peer-ID TLVs.
If rIKname-NAI is present, the authenticator MUST use that NAI to
route the message. If the rIKname-NAI is not present, the
authenticator MUST use the NAI in the Peer-ID to forward the message
via AAA. If neither are available, the authenticator MUST forward
the ERP messages to the local ER server. If none of these rules
apply, the authenticator MUST drop the packets silently.
The Authenticator sends the ERP messages just as it forwards other
EAP messages to the EAP server.
5.3.2.3. Server Operation
The server uses the following steps in processing EAP re-
authentication messages:
The server uses the rIKname to lookup the rIK. It first verifies
whether the sequence number is equal to or greater than the
expected sequence number. The server then proceeds to verify the
integrity of the message using the rIK, thereby verifying proof of
possession of that key by the peer. If the verifications fail,
the server sends an EAP-Finish/Re-auth message with a Failure
indication. Otherwise, it computes an rMSK from the rRK using the
sequence number.
5.3.3. EAP Finish/Re-auth Packet
The EAP-Finish/Re-auth packet contains the parameters shown in
Figure 8 :
Narayanan & Dondeti Expires August 7, 2008 [Page 26]
Internet-Draft ERP February 2008
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |R|B|L| Reserved | SEQ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: EAP Finish/Re-auth Packet
Type = 2.
Flags
'R' - The R flag is used as the Result flag - when set to 0, it
indicates success and when set to '1', it indicates a failure.
'B' - The B flag is used as the bootstrapping flag. If the
flag is turned on, the message is a bootstrap message.
'L' - The L flag is used to indicate the presence of the rRK
lifetime TLV.
The rest of the 5 bits are set to 0 and ignored on reception.
SEQ: A 16-bit sequence number is used for replay protection. The
SEQ number field is initialized to zero every time a new rRK is
derived.
TVs or TLVs: In the TV payloads, there is a 1-octet type payload
and a value with type-specific length. In the TLV payloads, there
is a 1-octet type payload and a 1-octet length payload. The
length field indicates the length of the value expressed in number
of octets.
rIKname: This is carried in a TV payload. The Type is 1 and
the value is a 64-bit field computed as specified in Section
Section 4.1.3 and is used to identify the rIK with which the
ERP messages are protected.
Narayanan & Dondeti Expires August 7, 2008 [Page 27]
Internet-Draft ERP February 2008
rIKname-NAI: This is carried in a TLV payload. The Type is 2.
The NAI is variable in length, not exceeding 253 octets. The
rIKname (username part of the NAI) is encoded in hexadecimal
values. If the rIK is derived from the EMSK, the realm part of
the NAI is the home domain identity and if the rIK is derived
from a DSRK, the realm part of the NAI is the domain identity
used in the derivation of the DSRK.
List of cryptosuites: This is a TLV payload. The Type is 5.
The value field contains a list of cryptosuites, each of size 1
octet. The cryptosuite values are as specified in Figure 7.
Lifetime: This is a TV payload. The Type is 6. The value
field is a 32-bit field and contains the lifetime of the rRK in
seconds.
In addition channel binding information may be included: see
Section 5.5 for additional discussion. See Figure 10 for
parameter specification. The server sends this information so
that the peer can verify the information seen at the lower
layer, if channel binding is to be supported.
Cryptosuite: This field indicates the integrity algorithm and the
PRF used for ERP. Key lengths and output lengths are either
indicated or are obvious from the cryptosuite name.
Authentication Tag: This field contains the integrity checksum
over the ERP packet, excluding the authentication tag field
itself. The length of the field is indicated by the Cryptosuite.
5.3.3.1. Server Operation
The server then sends an EAP-Finish/Re-auth message containing the
rIK sequence number, and the rIKname; this message is also integrity
protected with the rIK. The server may include one or more server-
ids with this message. The server-id is for the peer to use to send
future ERP messages.
The server transports the rMSK along with this message to the
authenticator. The rMSK is transported in a manner similar to the
MSK transport along with the EAP-Success message in a regular EAP
exchange.
5.3.3.2. Authenticator Operation
The Authenticator Operation is similar to that in processing an EAP-
Success message. It extracts the rMSK just as it does an MSK from a
AAA message containing an EAP-Success packet. The procedures for
Narayanan & Dondeti Expires August 7, 2008 [Page 28]
Internet-Draft ERP February 2008
RADIUS and Diameter are defined in [11] and [12] respectively.
5.3.3.3. Peer Operation
The peer uses the following steps in processing an EAP-Finish/Re-auth
message:
The peer first checks if the identifier in the EAP-Finish/Re-auth
message is the expected value.
The peer then checks to see if the sequence number in the received
message is the same as the sequence number in the EAP-Initiate/
Re-auth message; otherwise it logs an error.
Next, it uses the rIKname to lookup the appropriate rIK and
verifies the integrity of the message. If the verification
succeeds, it proceeds to the next step; otherwise, it logs an
error.
The peer then uses the sequence number to compute the rMSK.
The lower-layer security association protocol can be triggered at
this point.
5.3.4. TV and TLV Attributes
The TV attributes that may be present in the EAP-Initiate or EAP-
Finish messages are of the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: TV Attribute Format
The TLV attributes that may be present in the EAP-Initiate or EAP-
Finish messages are of the following format:
Narayanan & Dondeti Expires August 7, 2008 [Page 29]
Internet-Draft ERP February 2008
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: TLV Attribute Format
The following Types are defined in this document:
'1' - rIKname: TV Payload
'2' - rIKname-NAI: This is a TLV payload
'3' - Peer-ID: This is a TLV payload
'4' - Domain Identity: This is a TLV payload
'5' - cryptosuite list: This is a TLV payload
'6' - Lifetime: This is a TV payload.
The TLV type range of 128-191 is reserved to carry channel binding
information in the EAP-Initiate and Finish/Re-auth messages.
Below are the current assignments (all of them are TLVs):
'128' - Called-Station-Id [13]
'129' - Calling-Station-Id [13]
'130' - NAS-Identifier [13]
'131' - NAS-IP-Address [13]
'132' - NAS-IPv6-Address [14]
The length field indicates the length of the value part of the
attribute in octets.
5.4. Replay Protection
For replay protection, ERP uses sequence numbers. The sequence
number is maintained per rIK and is initialized to zero in both
directions. In the first EAP-Initiate/Re-auth message, the peer uses
the sequence number zero or higher. Note that the when the sequence
number rotates, the rIK MUST be changed. The server expects a
sequence number of zero or higher. When the server receives an EAP-
Narayanan & Dondeti Expires August 7, 2008 [Page 30]
Internet-Draft ERP February 2008
Initiate/Re-auth message, it uses the same sequence number in the
EAP-Finish Re-auth message. It increments the expected sequence
number by 1. The server accepts sequence numbers greater than or
equal to the expected sequence number.
If the peer sends an EAP-Initiate/Re-auth message, but does not
receive a response, it retransmits the request (with no changes to
the message itself) a pre-configured number of times before giving
up. However, it is plausible that the server itself may have
responded to the message and it was lost in transit. Thus the peer
MUST increment the sequence number and use the new sequence number to
send subsequent EAP re-authentication messages. The peer SHOULD
increment the sequence number by 1; however, it may choose to
increment by a larger number. When the sequence number rotates, the
peer MUST run full EAP authentication.
5.5. Channel Binding
ERP provides a protected facility to carry channel binding (CB)
information, according to the guidelines in Section 7.15 of [2]. The
TLV type range of 128-191 is reserved to carry CB information in the
EAP-Initiate/Re-auth and EAP-Finish/Re-auth messages. Called-
Station-Id, Calling-Station-Id, NAS-Identifier, NAS-IP-Address, and
NAS-IPv6-Address are some examples of channel binding information
listed in RFC 3748 and they are assigned values 128-132. Other
values may be added in future versions of this draft and the rest are
IANA managed based on IETF Consensus [15].
6. Transport of ERP Messages
Transport of ERP messages is specified in [10] and [11].
7. Security Considerations
This section provides an analysis of the protocol in accordance with
the AAA key management requirements specified in [16].
Cryptographic algorithm independence
The EAP Re-auth protocol satisfies this requirement. The
algorithm chosen by the peer for the PRF used in key derivation
as well as for the MAC generation is indicated in the EAP re-
authentication Response message. If the chosen algorithms are
unacceptable, the EAP server returns an EAP-Failure message in
response. Only when the specified algorithms are acceptable,
the server proceeds with derivation of keys and verification of
Narayanan & Dondeti Expires August 7, 2008 [Page 31]
Internet-Draft ERP February 2008
the proof of possession of relevant keying material by the
peer. A full blown negotiation of algorithms cannot be
provided in a single round trip protocol. Hence, while the
protocol provides algorithm agility, it does not provide true
negotiation.
Strong, fresh session keys
ERP results in the derivation of strong, fresh keys that are
unique for the given session. An rMSK is always derived on-
demand when the peer requires a key with a new authenticator.
The derivation ensures that the compromise of one rMSK does not
result in the compromise of a different rMSK at any time.
Limit key scope
The scope of all the keys derived by ERP are well defined. The
rRK and rIK are never shared with any entity and always remain
on the peer and the server. The rMSK is provided only to the
authenticator through which the peer performs the ERP exchange.
No other authenticator is authorized to use that rMSK.
Replay detection mechanism
For replay protection of ERP messages, a sequence number
associated with the rIK is used. The sequence number is
maintained by the peer and the server, and initialized to zero
when the rIK is generated. The peer increments the sequence
number by one after it sends an ERP message. The server
increments the sequence number when it receives and responds to
the message.
Authenticate all parties
The EAP Re-auth protocol provides mutual authentication of the
peer and the server. Both parties need to possess the keying
material that resulted from a previous EAP exchange in order to
successfully derive the required keys. Also, both the EAP re-
authentication Response and the EAP re-authentication
Information messages are integrity protected so that the peer
and the server can verify each other. When the ERP exchange is
executed with a local ER server, the peer and the local server
mutually authenticate each other via that exchange in the same
manner. The peer and the authenticator authenticate each other
in the secure association protocol executed by the lower layer
just as in the case of a regular EAP exchange.
Narayanan & Dondeti Expires August 7, 2008 [Page 32]
Internet-Draft ERP February 2008
Peer and authenticator authorization
The peer and authenticator demonstrate possession of the same
key material without disclosing it, as part of the lower layer
secure association protocol. Channel binding with ERP may be
used to verify consistency of the identities exchanged, when
the identities used in the lower layer differ from that
exchanged within the AAA protocol.
Keying material confidentiality
The peer and the server derive the keys independently using
parameters known to each entity. The rMSK is sent to the
authenticator via the AAA protocol. It is RECOMMENDED that the
AAA protocol be protected using IPsec or TLS so that the key
can be sent encrypted to the authenticator.
Confirm cryptosuite selection
Crypto algorithms for integrity and key derivation in the
context of ERP MAY be the same as that used by the EAP method.
In that case, the EAP method is responsible for confirming the
cryptosuite selection. Furthermore, the cryptosuite is
included in the ERP exchange by the peer and confirmed by the
server. The protocol allows the server to reject the
cryptosuite selected by the peer and provide alternatives.
When a suitable rIK is not available for the peer, the
alternatives may be sent in an unprotected fashion. The peer
is allowed to retry the exchange using one of the allowed
cryptosuites. However, any enroute modifications of the list
sent by the server in this case will go undetected. If the
server does have an rIK available for the peer, the list will
be provided in a protected manner and this issue does not
apply.
Uniquely named keys
All keys produced within the ERP context are uniquely named
using key name derivations specified in this documnet. Also,
the key names do not reveal any part of the keying material.
Prevent the domino effect
The compromise of one peer does not result in the compromise of
keying material held by any other peer in the system. Also,
the rMSK is meant for a single authenticator and is not shared
with any other authenticator. Hence, the compromise of one
authenticator does not lead to the compromise of sessions or
Narayanan & Dondeti Expires August 7, 2008 [Page 33]
Internet-Draft ERP February 2008
keys held by any other authenticator in the system. Hence, the
EAP Re-auth protocol allows prevention of the domino effect by
appropriately defining key scopes.
Bind key to its context
All the keys derived for ERP are bound to the appropriate
context using appropriate key labels. Lifetime of a child key
is less than or equal to that of its parent key as specified in
RFC 4962 [16]. The key usage, lifetime and the parties that
have access to the keys are specified.
Confidentiality of identity
Deployments where privacy is a concern may find the use of
rIKname-NAI to route ERP messages serves their privacy
requirements. Note that it is plausible to associate multiple
runs of ERP messages since the rIKname is not changed as part
of the ERP protocol. There was no consensus for that
requirement at the time of development of this specification.
If the rIKname is not used and the Peer-ID is used instead, the
ERP exchange will reveal the Peer-ID over the wire.
Authorization restriction
All the keys derived are limited in lifetime by that of the
parent key or by server policy. Any domain specific keys are
further restricted for use only in the domain for which the
keys are derived. All the keys specified in this document are
meant for use in ERP only. Any other restrictions of session
keys may be imposed by the specific lower layer and is out of
scope for this specification.
A denial of service attack on the peer may be possible when using the
EAP Initiate/Re-auth message. An attacker may send a bogus EAP-
Initiate/Re-auth message, which may be carried by the authenticator
in a RADIUS-Access-Request to the server; in response to that the
server may send an EAP-Finish/Re-auth with Failure indication in a
RADIUS Access-Reject message. Note that such attacks may be
plausible with the EAP-Start capability of IEEE 802.11 and other
similar facilities in other link layers and where the peer can
initiate EAP authentication; an attacker may use such messages to
start an EAP method run, which fails and may result in the server
sending a RADIUS Access-Reject message and thus resulting in the link
layer connections being terminated.
To prevent such DoS attacks, an ERP failure should not result in
deletion of any authorization state established by a full EAP
Narayanan & Dondeti Expires August 7, 2008 [Page 34]
Internet-Draft ERP February 2008
exchange. Alternately, the lower layers and AAA protocols may define
mechanisms to allow two link layer SAs derived from different EAP
keying materials for the same peer to exist so that smooth migration
from the current link layer SA to the new one is possible during
rekey. These mechanisms prevent the link layer connections from
being terminated when a re-authentication procedure fails due to the
bogus EAP-Initiate/Re-auth message.
When a DSRK is sent from a home ER server to a local domain server or
when a rMSK is sent from an ER server to an authenticator, in the
absence of end-to-end security between the entity that is sending the
key and the entity receiving the key, it is plausible for other
entities to get access to keys being sent to an ER server in another
domain. This mode of key transport is similar to that of MSK
transport in the context of EAP authentication. We further observe
that ERP is for access authentication and does not support end-to-end
data security. In typical implementations, the traffic is as such in
the clear beyond the access control enforcement point, typically the
authenticator or a delegate thereof. The model works as long as
entities in the middle of the network do not use keys intended for
other parties to steal service from an access network. If that is
not achievable, key delivery must be protected in an end-to-end
manner.
8. IANA Considerations
This document specifies IANA registration of two new EAP Codes:
o 5 (Initiate)
o 6 (Finish)
These values are in accordance with [2].
This document also specifies IANA registration of two new Types
related to Initiate and one for Finish message :
o 0 RESERVED
o 1 (Re-auth-Start, applies to Initiate Code only),
o 2 (Re-auth, applies to Initiate and Finish Codes).
o 3-191 IANA managed and assigned based on IETF Consensus [15],
o 192-255 Experimental/Private use.
Narayanan & Dondeti Expires August 7, 2008 [Page 35]
Internet-Draft ERP February 2008
.
Next, a number of type values corresponding to the TLVs within EAP-
Initiate and EAP-Finish messages. Those are as follows:
o rIKname: TV Payload. The Type is 1
o rIKname-NAI: This is a TLV payload. The Type is 2.
o Peer-ID: This is a TLV payload. The Type is 3.
o Domain Identity: This is a TLV payload. The Type is 4.
o Cryptosuite list: This is a TLV payload. The Type is 5.
o Lifetime: This is a TV payload. The Type is 6.
o 7-127: Used to carry other non-channel binding related attributes.
IANA managed and assigned based on IETF Consensus [15].
o The TLV type range of 128-191 is reserved to carry CB information
in the EAP-Initiate/Re-auth and EAP-Finish/Re-auth messages.
Below are the current assignments (all of them are TLVs):
* Called-Station-Id: 128
* Calling-Station-Id: 129
* NAS-Identifier: 130
* NAS-IP-Address: 131
* NAS-IPv6-Address: 132
133-191 Used to carry other channel binding related attributes.
IANA managed and assigned based on IETF Consensus [15].
o 192-255 is reserved for Experimental/Private use.
Further, this document registers a USRK label with a value "EAP re-
authentication Root Key" in accordance with [3].
We specify some cryptosuites below, in the format Integrity-
algorithm_PRF-name:
o 0 RESERVED
Narayanan & Dondeti Expires August 7, 2008 [Page 36]
Internet-Draft ERP February 2008
o 1 HMAC-SHA256-64_HMAC-SHA256
o 2 HMAC-SHA256-128_HMAC-SHA256
o 3 HMAC-SHA256-256_HMAC-SHA256
o 4-191 IANA managed and assigned based on IETF consensus [15]
o 192-255 is reserved for Experimental/Private use.
9. Acknowledgments
In writing this draft, we benefited from discussing the problem space
and the protocol itself with a number of folks including, Bernard
Aboba, Jari Arkko, Sam Hartman, Russ Housley, Joe Salowey, Jesse
Walker, Charles Clancy, Michaela Vanderveen, Kedar Gaonkar, Parag
Agashe, Dinesh Dharmaraju, Pasi Eronen, Dan Harkins, Yoshi Ohba, Glen
Zorn, Alan DeKok, Katrin Hoeper and other participants of the HOKEY
working group. The credit for the idea to use EAP-Initiate/
Re-auth-Start goes to Charles Clancy and the multiple link layer SAs
idea to mitigate the DoS attack goes to Yoshi Ohba. Katrin Hoeper
suggested the use of windowing technique to handle multiple
simultaneous ER exchanges. Many thanks to Pasi Eronen for the
suggestion to use hexadecimal encoding for rIKname when sent as part
of rIKname-NAI field.
10. References
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[3] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
"Specification for the Derivation of Root Keys from an Extended
Master Session Key (EMSK)", draft-ietf-hokey-emsk-hierarchy-03
(work in progress), January 2008.
[4] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network
Access Identifier", RFC 4282, December 2005.
[5] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
Narayanan & Dondeti Expires August 7, 2008 [Page 37]
Internet-Draft ERP February 2008
for Message Authentication", RFC 2104, February 1997.
10.2. Informative References
[6] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol
Method for 3rd Generation Authentication and Key Agreement
(EAP-AKA)", RFC 4187, January 2006.
[7] Lopez, R., Skarmeta, A., Bournelle, J., Laurent-Maknavicus, M.,
and J. Combes, "Improved EAP keying framework for a secure
mobility access service", IWCMC '06 Proceedings of the 2006
international conference on Wireless communications and mobile
computing, New York, NY, USA, 2006.
[8] Arbaugh, W. and B. Aboba, "Experimental Handoff Extension to
RADIUS", draft-irtf-aaaarch-handoff-04 (work in progress),
November 2003.
[9] Clancy, C., Nakhjiri, M., Narayanan, V., and L. Dondeti,
"Handover Key Management and Re-authentication Problem
Statement", draft-ietf-hokey-reauth-ps-07 (work in progress),
November 2007.
[10] Nakhjiri, M. and Y. Ohba, "Derivation, delivery and management
of EAP based keys for handover and re-authentication",
draft-ietf-hokey-key-mgm-02 (work in progress), January 2008.
[11] Gaonkar, K., Dondeti, L., and V. Narayanan, "RADIUS attributes
for Domain-specific Key Request and Delivery",
draft-gaonkar-radext-erp-attrs-02 (work in progress),
December 2007.
[12] Dondeti, L. and H. Tschofenig, "Diameter Support for EAP Re-
authentication Protocol", draft-dondeti-dime-erp-diameter-01
(work in progress), November 2007.
[13] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000.
[14] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001.
[15] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[16] Housley, R. and B. Aboba, "Guidance for Authentication,
Narayanan & Dondeti Expires August 7, 2008 [Page 38]
Internet-Draft ERP February 2008
Authorization, and Accounting (AAA) Key Management", BCP 132,
RFC 4962, July 2007.
Appendix A. Example ERP Exchange
0. Authenticator --> Peer: [EAP-Request/Identity]
1. Peer --> Authenticator: EAP Initiate/Re-auth(SEQ, rIKname,[Peer-ID],
cryptosuite,Auth-tag*)
1a. Authenticator --> Re-auth-Server: AAA-Request{Authenticator-Id,
EAP Initiate/Re-auth(SEQ,rIKname,[Peer-ID],
cryptosuite,Auth-tag*)
2. ER-Server --> Authenticator: AAA-Response{rMSK,
EAP-Finish/Re-auth(SEQ,rIKname,
cryptosuite,[CB-Info],Auth-tag*)
2b. Authenticator --> Peer: EAP-Finish/Re-auth(SEQ,rIKname,
cryptosuite,[CB-Info],Auth-tag*)
* Auth-tag computation is over the entire EAP Initiate/Finish message;
the code values for Initiate and Finish are different and thus
reflection attacks are mitigated.
Figure 11: ERP Exchange
Authors' Addresses
Vidya Narayanan
Qualcomm, Inc.
5775 Morehouse Dr
San Diego, CA
USA
Phone: +1 858-845-2483
Email: vidyan@qualcomm.com
Narayanan & Dondeti Expires August 7, 2008 [Page 39]
Internet-Draft ERP February 2008
Lakshminath Dondeti
Qualcomm, Inc.
5775 Morehouse Dr
San Diego, CA
USA
Phone: +1 858-845-1267
Email: ldondeti@qualcomm.com
Narayanan & Dondeti Expires August 7, 2008 [Page 40]
Internet-Draft ERP February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Narayanan & Dondeti Expires August 7, 2008 [Page 41]
| PAFTECH AB 2003-2026 | 2026-04-22 23:14:29 |