One document matched: draft-ietf-hokey-key-mgm-06.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='../rfc2629xslt/rfc2629.xslt' ?>
<!--changing the DTD with the DTD file saved locally -->
<!--<!DOCTYPE rfc SYSTEM "rfcdtd.dtd"> -->
<?rfc iprnotified="yes" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc inline="no"?>
<!DOCTYPE rfc SYSTEM "../rfc2629.dtd" [
<!ENTITY radext-extended-attributes PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-radext-extended-attributes.xml'>
<!ENTITY radext-radsec PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-radext-radsec.xml'>
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2865 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml'>
<!ENTITY rfc3748 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml'>
<!ENTITY rfc3579 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3579.xml'>
<!ENTITY rfc4072 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4072.xml'>
<!ENTITY rfc4107 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4107.xml'>
<!ENTITY rfc4120 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4120.xml'>
<!ENTITY rfc4962 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4962.xml'>
<!ENTITY rfc5169 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5169.xml'>
<!ENTITY rfc5247 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5247.xml'>
<!ENTITY rfc5295 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5295.xml'>
<!ENTITY rfc5296 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5296.xml'>
]>
<rfc
category="std"
ipr="pre5378Trust200902"
docName='draft-ietf-hokey-key-mgm-06'>
<front>
<title abbrev="HOKEY Key Distribution">
Distribution of EAP based keys for handover and re-authentication
</title>
<author role="editor" initials="K." surname="Hoeper"
fullname="Katrin Hoeper">
<organization abbrev="Motorola">
Motorola
</organization>
<address>
<postal>
<street>1301 E Algonquin Road</street>
<city>Schaumburg</city>
<region>IL</region>
<code>60196</code>
<country>USA</country>
</postal>
<phone>+1 847 576 4714</phone>
<email>khoeper@motorola.com</email>
</address>
</author>
<author role="editor" initials="Y." surname="Ohba"
fullname="Yoshihiro Ohba">
<organization abbrev="Toshiba">
Toshiba America Research, Inc.
</organization>
<address>
<postal>
<street>1 Telcordia Drive</street>
<city>Piscataway</city>
<region>NJ</region>
<code>08854</code>
<country>USA</country>
</postal>
<phone>+1 732 699 5305</phone>
<email>yohba@tari.toshiba.com</email>
</address>
</author>
<date month="April" year="2009"/>
<workgroup></workgroup>
<?rfc compact="yes" ?>
<abstract>
<t>
This document describes a mechanism for delivering root keys from an Extensible Authentication Protocol (EAP)
server to another network server that requires the keys for offering security protected services, such as re-authentication, to an EAP peer.
The distributed root key can be either a usage-specific root key (USRK), a domain-specific root key (DSRK)
or a domain-specific usage-specific root key (DSUSRK) that has been derived from an Extended Master Session Key (EMSK) hierarchy previously
established between the EAP server and an EAP peer. The document defines a key distribution exchange (KDE) protocol using
Remote Authentication Dial In User Service (RADIUS) that can distribute these different types of root keys and discusses its security requirements.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t> The Extensible Authentication Protocol (EAP) <xref target='RFC3748'/> is an authentication framework supporting authentication methods
that are specified in EAP methods. By definition, any key-generating EAP method derives an Master Session Key (MSK) and an Extended Master
Session Key (EMSK).
<xref target='RFC5295'/> reserves the EMSK for the sole purpose of deriving root keys that
can be used for specific purposes called usages. In particular, <xref target='RFC5295'/> defines
how to create a usage-specific root key (USRK) for bootstrapping
security in a specific application, a domain-specific root key (DSRK) for bootstrapping
security of a set of services within a domain, and a usage-specific DSRK (DSUSRK) for a specific application within a domain.</t>
<t> MSK and EMSK may be used to derive further keying material for a variety of security mechanisms <xref target='RFC5247'/>. For example, the MSK
has been widely used for bootstrapping the wireless link security associations between the
peer and the network attachment points. However, performance as well as security issues
arise when using the MSK and the current bootstrapping methods in mobile scenarios that require handovers,
as described in <xref target='RFC5169'/>. To address handover latencies and other shortcomings,
<xref target='RFC5296'/> specifies an EAP re-authentication protocol (ERP) that
uses keys derived from EMSK or DSRK to enable efficient re-authentications in handover scenarios. <xref target='RFC5295'/>
and <xref target='RFC5296'/> both do not specify how root keys are delivered to the network server requiring the key. Such a key delivery mechanism
is essential because
the EMSK cannot leave the EAP server (<xref target='RFC5295'/>) but root keys are needed by other network servers disjoint with the EAP server.
For example,
in order to enable an EAP peer to re-authenticate to a network during a handover,
certain root keys need to be made available by the EAP server to the server carrying out the re-authentication.</t>
<t>This document specifies a mechanism for the delivery of EMSK child keys from the
server holding the EMSK or a root key to another network server that requests a root key
for providing protected services (such as re-authentication and other usage and domain-specific services) to EAP peers. In the remainder of this
document, a server delivering root keys is referred to as Key Delivering Server (KDS) and a server authorized to request and receive
root keys from a KDS is referred to as Key Requesting Server (KRS).
The Key Distribution Exchange (KDE) protocol defined in this document uses RADIUS <xref target='RFC2865'/>, <xref target='RFC3579'/> and has several variants depending
on the type of key that is requested and delivered (i.e. DRSK, USRK, and DSUSRK). The document also describes security requirements for the secure
key delivery over RADIUS.</t>
</section>
<section title="Terminology">
<t>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 <xref
target='RFC2119'/>.</t>
<list style="hanging">
<t hangText="USRK:">Usage-Specific Root Key. A root key that is derived
from the EMSK, see <xref target='RFC5295'/>.</t>
<t hangText="USR-KH:">USRK Holder. A network server that is authorized to request and receive a USRK from the EAP server. The USR-KH can be
an AAA server or dedicated service server.</t>
<t hangText="DSRK:">Domain-Specific Root Key. A root key that is
derived from the EMSK, see <xref target='RFC5295'/>.</t>
<t hangText="DSR-KH:">DSRK Holder. A network server that is authorized to request and receive a DSRK from the EAP server.
The most likely implementation of a DSR-KH is an AAA server in a domain, enforcing the policies for the usage of the DSRK within this domain.</t>
<t hangText="DSUSRK:">Domain-Specific Usage-Specific Root Key. A
root key that is derived from the DSRK, see <xref target='RFC5295'/>.</t>
<t hangText="DSUSR-KH:">DSUSRK holder. A network server authorized to request and receive a DSUSRK from the DSR-KH.
The most likely implementation of a DSUSR-KH is an AAA server in a domain, responsible for a particular service offered within this domain.</t>
<t hangText="RK:"> Root Key. An EMSK child key, i.e. a USRK, DSRK, or DSUSRK.</t>
<t hangText="KDS:">Key Delivering Server. A network server that holds an EMSK or DSRK and delivers root keys to KRS requesting root keys. The EAP
server and DSR-KH can act as KDS.</t>
<t hangText="KRS:">Key Requesting Server. A network server that shares an interface with a KDS and is authorized to request root keys from the KDS.
USR-KH, DSR-KH, and DSUSR-KH can all act as KRS.</t>
</list>
</section>
<section title="Key Delivery Architecture">
<t>
An EAP server carries out the EAP authentications with EAP peers but is typically not making any, potentially future, service authorization
decisions involving peers. Authorizations as well as
the service provisioning are handled by the respective network server offering the requested service. These servers can be AAA servers or
other service servers. Whenever EAP-based keying material is used to protect a requested service, a network server needs to request the
root key associated with the offered service from the respective KDS.
This kind of key requests and distributions are necessary because an EMSK cannot leave the EAP
server (<xref target='RFC5295'/>). Hence, any root key that is directly derived from an EMSK must be derived and delivered
by the EAP server itself, whereas root keys derived from EMSK child keys, such as a DSUSRK, can be requested from the respective root key holder.
Hence, a KDS can be either the EAP server or a DSRK holder (DSR-KH), whereas a KRS can be either a USRK holder (USR-KH), a DSR-KH or a
DSUSRK holder (DSUSR-KH).</t>
<t> The KRS needs to share an interface with the KDS to be able to send all necessary input data to
derive the requested key and to receive the requested key. The provided data includes the Key Derivation Function (KDF) that should be used to
derive the requested key. The KRS uses the received root key to derive further keying material in order to secure its offered services.
Every KDS is responsible for storing and protecting the received root key as well as the derivation and distribution of any child key derived
from the root key. An example of a key delivery architecture is illustrated in <xref target='fig:fig1'/> showing the different types of KRS
and their interfaces to the KDS.
</t>
<figure anchor='fig:fig1' title='Example Key Delivery Architecture for the Different KRS and KDS'>
<artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP server |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | | \
/ | | \
/ | | \
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
| USR-KH1 | | USR-KH2 | | DSR-KH1 | | DSR-KH2 |
| HOKEY server| | XYZ server| |Domain 1 | | Domain 2|
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
/ |
/ |
/ |
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| DSUSR-KH | | DSUSR-KH2 |
| Domain 1 | | Domain 2 |
|Home domain | |Visited domain |
|HOKEY server | |HOKEY server |
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
</artwork>
</figure>
</section>
<section title="Key Distribution Exchange (KDE)" anchor='sec-kde'>
<t> In this section, a generic mechanism for a key
distribution exchange (KDE)over RADIUS is described in which a root key (RK) is distributed from a
KDS to a KRS. It is required that the communication path between the
KDS and the KRS is protected by the use of an
appropriate RADIUS transport security mechanism (see <xref
target='section-security-consideration'/>). Here, it is assumed that the KRS and the KDS are separate entities,
logically if not physically, and the delivery of the
requested RK is specified accordingly. </t>
<t>The key distribution exchange consists of one roundtrip, i.e. two messages between the KRS and the KDS, as illustrated in
<xref target='fig:fig2'/>. First, the KRS sends a KDE-Request consisting of a RADIUS Access-Request message with a KDE
attribute in which the K-flag is cleared. As a response, the KDS sends a KDE-Response consisting of a RADIUS Access-Accept message with a
KDE attribute in which
the K-flag set. The RADIUS
KDE attribute used in this exchange is defined in <xref target='section-message-format'/>.
</t>
<figure anchor='fig:fig2' title='KDE Message Flow'>
<artwork xml:space="preserve"><![CDATA[
KRS KDS
-------- -------
| |
| |
| KDE-Request (KRT) |
| (i.e., RADIUS Access-Request{KDE(K=0)}) |
|----------------------------------------->|
| KDE-Response(KDT) |
| (i.e., RADIUS Access-Accept{KDE(K=1)}) |
|<-----------------------------------------|
]]>
</artwork>
</figure>
<list style="hanging">
<t hangText="KDE-Request:">The KRS sends a
Key Request Token (KRT) to the KDS. The contents of KRT are
detailed below.</t>
<t hangText="KDE-Response:">As a response, the KDS sends the requested RK to the KRS
wrapped inside a token called Key Delivery Token (KDT). The contents of KDT are detailed below.</t>
</list>
<list style="hanging">
<t hangText="KRT : (PID, KT, KL)">
<vspace blankLines="1"/>KRT carries
the identifiers of the peer (PID), the key type (KT)
and the key label (KL). See <xref target='RFC5295'/> for the
specification of key labels.
</t>
<t hangText="KDT : (KT, KL, RK, KN_RK, LT_RK)">
<vspace blankLines="1"/> KDT carries the root key (RK) to be
distributed to the KRS, as well as the key type (KT), the key label (KL), the key name (KN_RK) and the lifetime of RK (LT_RK).</t>
</list>
<section title='Context and Scope for Distributed Keys'>
<t>The key lifetime of each distributed key MUST NOT be greater
than that of its parent key.</t>
<t>The key context of each distributed key is determined by the
sequence of KTs in the key hierarchy. When a DSRK is being
delivered and the DSRK applies to only a specific set of
services, the service types may need to be carried as part of
context for the key. Carrying such a specific set of services
is outside the scope of this document.</t>
<t>The key scope of each distributed key is determined by the
sequence of (PID, KT, KL)-tuples in the key hierarchy. The
KDF used to generate the requested keys
includes context and scope information, thus, binding the key to
the specific channel <xref target='RFC5295'/>.</t>
</section>
<section title="Key Distribution Exchange Scenarios">
<t> Given the three types of KRS, there are three scenarios for the distribution of EMSK child keys.
For all scenarios, the trigger and mechanism
for key delivery may involve a specific request from an EAP peer and/or
another intermediary (such as an authenticator). For simplicity, it is assumed that USR-KHs reside in the same domain as the EAP server.
</t>
<list style='hanging'>
<t hangText='Scenario 1: EAP server to USR-KH:'>In this
scenario, the EAP server delivers a USRK to a USR-KH.
</t>
<t hangText='Scenario 2: EAP server to DSR-KH:'>In this
scenario, the EAP server delivers a DSRK to a DSR-KH.
</t>
<t hangText="Scenario 3: DSR-KH to DSUSR-KH:">
In this scenario, a DSR-KH in a specific domain delivers keying
material to a DSUSR-KH in the same domain.
</t>
</list>
<t>The key distribution exchanges for Scenario 3 can be combined
with the key distribution exchanges for Scenario 2 into a single
roundtrip exchange as shown in <xref target='fig:fig6'/>.
Here, KDE-Request and KDE-Response are messages for Scenarios 2, whereas
KDE-Request' and KDE-Response' are messages for Scenarios 3.
</t>
<figure anchor='fig:fig6' title='Combined Message Exchange'>
<artwork><![CDATA[
DSUSR-KH DSR-KH EAP Server
-------- ------- -----
| KDE-Request'(KRT') | KDE-Request(KRT) |
|------------------------>|-------------------------->|
| KDE-Response'(KDT') | KDE-Response(KDT) |
|<----------------------- |<--------------------------|
| | |
]]>
</artwork>
</figure>
</section>
</section>
<section title='RADIUS KDE Attribute' anchor='section-message-format'>
<t>
This section defines the format of the RADIUS KDE attribute. See <xref
target='section-security-consideration'/> for security requirements
on transporting this RADIUS attribute.
</t>
<artwork xml:space="preserve">
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 |K| Reserved | Key Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Name (included only when K=1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key (included only when K=1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Lifetime (included only when K=1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
<list style='hanging'>
<t hangText='Type'><vspace blankLines="1"/> = X (KDE) [X to be
assigned by IANA].</t>
<t hangText='Length'><vspace blankLines="1"/> >4 </t>
<t hangText='K (Key included)'><vspace blankLines="1"/> A flag to
indicate whether this attribute contains a Key field. This flag
is set for a KDE-Response. This flag is cleared for a
KDE-Request.</t>
<t hangText='Reserved'><vspace blankLines="1"/> Reserved bits.
All reserved bits MUST be set to 0 by the sender and ignored by
the recipient.
</t>
<t hangText='Key Type'><vspace blankLines="1"/> A field to
contain a KT. The following KT values are defined: 0 (DSRK), 1
(USRK) and 2 (DSUSRK).</t>
<t hangText='Key Label'><vspace blankLines="1"/> A field to
contain a key label (KL). The first octet contains the length of
the rest of this field in octets.
</t>
<t hangText='Key Name'><vspace blankLines="1"/> A field to
contain a KN_RK. The first octet contains the length of the
rest of this field in octets. This field is contained if and
only if K-flag is set.</t>
<t hangText='Key'><vspace blankLines="1"/> A field to contain a
RK. The first octet contains the length of the rest of this
field in octets. This field is contained if and only if K-flag
is set.</t>
<t hangText='Key Lifetime'><vspace blankLines="1"/> A 4-octet
unsigned integer to indicate a LT_RK. This field is contained
if and only if K-flag is set.</t>
</list>
</section>
<section title='KDE used in the EAP Re-authentication Protocol (ERP)'>
<t>
This section describes how the presented KDE should be used to request and deliver the root keys used for re-authentication
in the EAP Re-authentication Protocol (ERP)
defined in <xref target='RFC5296'/>. ERP supports two forms of bootstrapping,
implicit as well as explicit bootstrapping, and KDE is discussed for both cases in the remainder of this section.
</t>
<t>
In implicit bootstrapping the local EAP Re-authentication (ER) server requests the DSRK from the home AAA server during the initial EAP exchange.
Here, the local ER server
acts as the KRS and the home AAA server as the KDS. In this case, the local ER server
requesting the DSRK MUST include a KDE attribute with the K-flag
cleared in the RADIUS Access-Request message that carries the
first EAP-Response message from the peer. A value
of the RADIUS User-Name attribute is used as the PID. Upon receiving a valid KDE-Request, the home AAA server
includes a KDE attribute with K-flag set in the RADIUS
Access-Accept message that carries the EAP-Success message.
</t>
<t>
Explicit bootstrapping is initiated by a peer if it doesn't know the domain. Here, EAP-Initiate and EAP-Finish messages
are exchanged between the
peer and the home AAA server, with the bootstrapping flag in the
EAP-Initiate message set. In this case, the local ER server (acting as KRS) MUST include a KDE attribute with the K-bit cleared in a RADIUS
Access-Request message that carries an EAP-Initiate message with the bootstrapping flag turned on. A value
of the RADIUS User-Name attribute is used as the PID. In its response, the home AAA server (acting as KDS) MUST include a KDE attribute with
K-flag set in a RADIUS Access-Accept message that carries an
EAP-Finish message for which the
bootstrapping flag is set.
</t>
</section>
<section title='Conflicting Messages'>
<t>
In addition to the rules specified in Section 2.6.3. of <xref
target='RFC3579'/>, the following combinations SHOULD NOT be sent
by a RADIUS Server:
</t>
<artwork>
Access-Accept/EAP-Message/EAP-Finish with 'R' flag set to 1
Access-Reject/EAP-Message/EAP-Finish with 'R' flag set to 0
Access-Reject/Keying-Material
Access-Reject/KDE
Access-Challenge/EAP-Message/EAP-Initiate
Access-Challenge/EAP-Message/EAP-Finish
Access-Challenge/KDE
</artwork>
</section>
<section title='Security Considerations'
anchor='section-security-consideration'>
<t>
This section provides security requirements and an analysis on
transporting EAP keying material using RADIUS.
</t>
<section title='Requirements on RADIUS Key Transport'>
<t>
RADIUS messages that carry a KDE attribute MUST be encrypted,
integrity-protected and replay-protected with a security association
created by a RADIUS transport protocol such as TLS <xref
target='I-D.ietf-radext-radsec'/>. When there is an
intermediary such as a RADIUS proxy on the path between the
KRS and the KDS, there will be a series of
hop-by-hop security associations along the path. The use of
hop-by-hop security associations implies that the intermediary
on each hop can access the distributed keying material. Hence
the use of hop-by-hop security SHOULD be limited to an
environment where an intermediary is trusted not to abuse the
distributed key material.
</t>
</section>
<section title='Distributing RK without Peer Consent'>
<t>When a KDE-Request message is sent as a result of explicit ERP
bootstrapping <xref target='RFC5296'/>, cryptographic
verification of peer consent on distributing a RK is provided by
the integrity checksum of the EAP-Initiate message with the
bootstrapping flag turned on.
</t>
<t>When a KDE-Request message is sent as a result of implicit ERP
bootstrapping <xref target='RFC5296'/>, cryptographic
verification of peer consent on distributing a RK is not
provided. As a result, it is possible for a KRS to
request a RK from the home server and obtain the RK even if the peer
does not support ERP, which can lead to an unintended
use of a RK and failed authentication attempts.
</t>
</section>
</section>
<section title='IANA consideration'>
<t>This document defines a new namespace for maintaining Key Type
used to identify the type of the root key RK. The range of values 0 - 255 are
for permanent, standard message types, allocated by IETF Review
<xref target='IANA'/>. This document defines the values 0 (DSRK), 1
(USRK) and 2 (DSUSRK).</t>
<t>This document defines a new RADIUS Attribute Type for KDE
in <xref target='section-message-format'/>.
</t>
</section>
<section title='Acknowledgements'>
<t> The author would like to thank Dan Harkins, Chunqiang Li,
Rafael Marin Lopez and Charles Clancy for their valuable comments.
</t>
</section>
<section title='Contributors'>
<t>
The following people contributed to this document.
</t>
<artwork>
Madjid Nakhjiri (madjid.nakhjiri@motorola.com)
Kedar Gaonkar (kgaonkar3@gatech.edu)
Lakshminath Dondeti (ldondeti@qualcomm.com)
Vidya Narayanan (vidyan@qualcomm.com)
Glen Zorn (glenzorn@comcast.net)
</artwork>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc2119;
&rfc2865;
&rfc3748;
&rfc5295;
&rfc5296;
<reference anchor='IANA'>
<front>
<title>
Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author initials="T." surname="Narten"/>
<author initials="H." surname="Alvestrand"/>
<date month='May' year='2008'/>
</front>
<seriesInfo name="" value="BCP 26, RFC 5226" />
</reference>
</references>
<references title='Informative references'>
&rfc3579;
&rfc5247;
&rfc5169;
&radext-radsec;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:12:03 |