• Aucun résultat trouvé

This document is a product of the Internet Engineering Task Force (IETF)

N/A
N/A
Protected

Academic year: 2022

Partager "This document is a product of the Internet Engineering Task Force (IETF)"

Copied!
7
1
0
En savoir plus ( Page)

Texte intégral

(1)

Category: Standards Track A. Yegin ISSN: 2070-1721 Samsung March 2010

Definition of Master Key between PANA Client and Enforcement Point Abstract

This document defines a master key used between a client of the

Protocol for carrying Authentication for Network Access (PANA) and an enforcement point, for bootstrapping lower-layer ciphering. The master key is derived from the Master Session Key of the Extensible Authentication Protocol as a result of successful PANA

authentication. The master key guarantees cryptographic independence among enforcement points bootstrapped from PANA authentication across different address families.

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at

http://www.rfc-editor.org/info/rfc5807.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents

(http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents

carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

(2)

Table of Contents

1. Introduction . . . 3

1.1. Specification of Requirements . . . 4

2. Terminology . . . 4

3. PaC-EP Master Key . . . 4

3.1. Key Name of PEMK . . . 5

3.2. Scope of PEMK . . . 5

3.3. Context of PEMK . . . 5

3.4. Lifetime of PEMK . . . 5

4. Security Considerations . . . 5

4.1. Channel Binding . . . 5

4.2. Guideline for Distributing PEMK from PAA to EP . . . 6

5. Acknowledgments . . . 6

6. References . . . 6

6.1. Normative References . . . 6

6.2. Informative References . . . 7

(3)

1. Introduction

The Protocol for carrying Authentication for Network Access (PANA) [RFC5191] is designed to facilitate network access authentication and authorization of clients in access networks. It carries Extensible Authentication Protocol (EAP) [RFC3748] between a PANA Client (PaC) and a PANA Authentication Agent (PAA) where the PAA functions as an authentication gateway to the Authentication Server (AS). The PANA framework [RFC5193] defines an another entity referred to as an Enforcement Point (EP), which resides in the access network and allows access (data traffic) of authorized PaCs while preventing access of others depending on the PANA authentication and

authorization result (Figure 1). The EP and PAA may be implemented on the same device or separate devices.

RADIUS, Diameter,

+---+ PANA +---+ LDAP, API, etc. +---+

| PaC |<--->| PAA |<--->| AS | +---+ +---+ +---+

^ ^ | | | +---+ |

IKE, +--->| EP |<---+ ANCP, API, etc.

4-way handshake, +---+

etc. . . . v

Data traffic

Figure 1: PANA Functional Model

The EP uses non-cryptographic or cryptographic filters to selectively allow and discard data packets. These filters may be applied at the link-layer or the IP-layer [PANA-IPSEC]. When cryptographic access control is used, a secure association protocol [RFC3748] needs to run between the PaC and EP. After completion of the secure association protocol, link- or network-layer per-packet security (for example, IPsec ESP) is enabled for integrity protection, data origin

authentication, replay protection, and optionally confidentiality protection.

This document defines the PaC-EP Master Key (PEMK) that is used by a secure association protocol as the pre-shared secret between the PaC and EP to enable cryptographic filters in the access network. The PEMK is defined to guarantee cryptographic independence among EPs bootstrapped from PANA authentication across different address

(4)

families. This document also describes a guideline for distributing PEMKs from the PAA to EP.

This document does not specify a mechanism for a PaC to know whether the lower layer requires a secure association protocol or the pre- shared secret for the secure association protocol needs to be bootstrapped from PANA authentication. Such a mechanism may be defined by each lower-layer protocol.

1.1. Specification of Requirements

In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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 [RFC2119].

2. Terminology

This document reuses the following terms defined in [RFC5191]: PaC (PANA Client), PAA (PANA Authentication Agent), EP (Enforcement Point), MSK (Master Session Key), PANA Session, and Session Identifier.

3. PaC-EP Master Key

A PEMK (PaC-EP Master Key) is derived from an available MSK. The PEMK is 64 octets in length and is calculated as follows:

PEMK = prf+(MSK, "IETF PEMK" | SID | KID | EPID) where | denotes concatenation.

o The prf+ function is defined in IKEv2 [RFC4306]. The pseudo- random function used for the prf+ function is specified in the PRF-Algorithm AVP carried in a PANA-Auth-Request message with ’S’

(Start) bit set.

o "IETF PEMK" is the ASCII code representation of the non-NULL terminated string (excluding the double quotes around it).

o SID is a four-octet Session Identifier [RFC5191].

o KID is the content of the Key-ID AVP [RFC5191] associated with the MSK.

o EPID is the identifier of the EP. The first two octets represents the AddressType, which contains an Address Family defined in

[IANAADFAM]. The remaining octets encode the address value. The

(5)

length of the address value is determined by the AddressType. The AddressType is used to discriminate the content and format of the remaining octets for the address value. The use of the

combination of address family and address value guarantees the cryptographic independence of PEMKs among multiple EPs that are bootstrapped from PANA authentication across multiple address families. How a PaC discovers an EPID is out of the scope of this document.

3.1. Key Name of PEMK

The key name of the PEMK is defined as follows.

PEMKname = SHA1(EPID | SID | KID), where SHA1 denotes the SHA-1 algorithm specified in [SHS]. Inclusion of the EPID, SID, and KID provides uniqueness of PEMK names among multiple PaC-EP pairs under a given PAA.

3.2. Scope of PEMK

One PEMK is used between one PaC and one EP. A PEMK MUST NOT be shared among multiple PaCs or EPs.

3.3. Context of PEMK

A PEMK is used as the pre-shared key of the secure association protocol in the scope of the PEMK. A PEMK MUST NOT be used for any other usage.

3.4. Lifetime of PEMK

The lifetime of a PEMK MUST be less than or equal to the lifetime of the MSK from which it is derived. At the end of the lifetime, the PEMK and its associated states MUST be deleted.

4. Security Considerations

The following considerations are specifically made to follow the Authentication, Authorization, and Accounting (AAA) key management guidance [RFC4962]. Other AAA key management requirements such as key lifetime, key scope, key context, and key name are described in Section 3.

4.1. Channel Binding

Since the device identifier of the EP is involved in the key

derivation function, Channel Binding on a PEMK is made between the PaC and PAA at the time when the PEMK is generated. If a malicious

(6)

EP advertises a different device identifier than that registered with the PAA, the malicious attempt will not succeed since the secure association protocol will fail due to the difference in the PEMK values calculated by the PaC and the EP.

4.2. Guideline for Distributing PEMK from PAA to EP

When an EP is implemented on the same device as the PAA, no protocol needs to be used for distributing a PEMK from the PAA to the EP.

In the case where the EP is implemented on a separate device from the PAA, a protocol is needed to distribute a PEMK from the PAA to the EP. Such a key distribution protocol may depend on the architecture and deployment using PANA. A key distribution protocol for a PEMK MUST ensure that the PEMK is encrypted as well as integrity and

replay protected, with a security association between the PAA and EP, where the security association MUST be cryptographically bound to the identities of the PAA and EP known to the PaC.

5. Acknowledgments

We would like to thank Jari Arkko, Basavaraj Patil, Pasi Eronen, Russ Mundy, Alexey Melnikov, and all members of the PANA working group for their valuable comments to this document.

6. References

6.1. Normative References

[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.

[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.

[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008.

[SHS] National Institute of Standards and Technology, U.S.

Department of Commerce, "Secure Hash Standard", NIST FIPS PUB 180-2, August 2002.

[IANAADFAM] IANA, "Address Family Numbers", http://www.iana.org.

(7)

6.2. Informative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.

[RFC5193] Jayaraman, P., Lopez, R., Ohba, Y., Parthasarathy, M., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA) Framework", RFC 5193, May 2008.

[PANA-IPSEC] Parthasarathy, M., "PANA Enabling IPsec based Access Control", Work in Progress, July 2005.

Authors’ Addresses Yoshihiro Ohba

Toshiba Corporate Research and Development Center 1 Komukai-Toshiba-cho

Saiwai-ku, Kawasaki, Kanagawa 212-8582 Japan

Phone: +81 44 549 2230

EMail: yoshihiro.ohba@toshiba.co.jp

Alper Yegin Samsung Istanbul Turkey

EMail: alper.yegin@yegin.org

Références

Documents relatifs

When a transit node’s policy permits it to support reroute request processing and local repair, the node MUST examine incoming PathErr messages to see it the node can perform

This memo describes how the &#34;authPassword&#34; Lightweight Directory Access Protocol (LDAP) attribute can be used for storing secrets used by the Salted Challenge

Each response may be followed by a response code (see Section 1.3) and by a string consisting of human-readable text in the local language (as returned by the LANGUAGE

The DCSite captures the type, identifier, location, and other pertinent information about the credential gathering process, or data collection site, used in the

It provides a collection of data objects that can be queried using the SNMP protocol and represent the current status of the NTP entity.. This includes general information

This document defines a DHCPv6 option and associated suboptions to provide Network Time Protocol version 4 [RFC5905] or greater server location information to DHCPv6

As a more efficient alternative, if an HTTP server wishes to offer the ability to subscribe to the state of several HTTP resources in a single SUBSCRIBE request, it returns a

As a result, even if a malicious user were able to determine the external (mapped) IPv4 address and port assigned to the Teredo client, the malicious user would still need

This document specifies the payload format for packetization of GSM Half Rate (GSM-HR) codec [TS46.002] encoded speech signals into the Real-time Transport Protocol

The Hypertext Transfer Protocol (HTTP) Extensions for the Web Distributed Authoring and Versioning (WebDAV) do not define the behavior for the &#34;POST&#34; method when

In cases where the Registration Document is to be published in a specification other than RFC, the authors must inform IANA, as soon as the Enumservice Specification has

As specified in RFC 3920, the XMPP address format reuses the &#34;stringprep&#34; technology for preparation of non-ASCII characters [STRINGPREP], including the Nameprep

Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without

To address this problem, this document defines a TLV to be added to purges to record the system ID of the IS generating the purge.. Field experience has shown

This document includes specifications for the United States of America (USA) Federal Information Processing Standard (FIPS) Secure Hash Algorithms (SHAs), code to implement

As with the LSRR and SSRR options, if the packet does not pass these checks it should be dropped, and this event should be logged (e.g., a counter could be incremented to

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort

Authentication-Results field in its header hash (in this case, the MLM), the Verifier is in a position to believe that a valid Author signature was present on the message.

o A local Signal Fail indication on the protection path SHALL cause the LER to go into local Unavailable state and begin transmission of an SF(0,0) message, if the

[RFC4869] proposed four new UI suites based on implementations of the United States National Security Agency’s Suite B algorithms (see [SuiteB]).. As with the VPN suites,

If configured at a minimum level of security of 192 bits, ECDSA-384 MUST be used by both parties for IKEv2 authentication.. Initiators and responders in a system configured at

The Sieve Notify extension specifies that notification methods MUST provide mechanisms for avoiding notification loops. In this case, the SIP protocol itself prevents loops,

The AS_SET path segment type of the AS_PATH attribute (Sections 4.3 and 5.1.2 of [RFC4271]) is created by a router that is performing route aggregation and contains an