One document matched: draft-clancy-emu-aaapay-02.txt
Differences from draft-clancy-emu-aaapay-01.txt
Network Working Group T. Clancy
Internet-Draft LTS
Intended status: Standards Track A. Lior
Expires: November 4, 2009 BWS
G. Zorn, Ed.
Network Zen
May 3, 2009
EAP Method Support for Transporting AAA Payloads
draft-clancy-emu-aaapay-02.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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 November 4, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
Clancy, et al. Expires November 4, 2009 [Page 1]
Internet-Draft EAP-AAAPAY May 2009
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document defines bindings for existing EAP methods to transport
Diameter AVPs, called "AAA payloads". The primary application is to
support EAP channel bindings, but this could be used for other
applications as well.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview and Requirements . . . . . . . . . . . . . . . . . . . 3
4. AAA Payload Format . . . . . . . . . . . . . . . . . . . . . . 4
5. Bindings for Existing EAP Methods . . . . . . . . . . . . . . . 5
5.1. Generalized Pre-Shared Key (GPSK) . . . . . . . . . . . . . 5
5.2. Pre-Shared Key (PSK) . . . . . . . . . . . . . . . . . . . 5
5.3. Passord Authenticated Exchange (PAX) . . . . . . . . . . . 6
5.4. Tunneled Transport Layer Security (TTLS) . . . . . . . . . 6
5.5. Flexible Authentication via Secure Tunneling (FAST) . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Clancy, et al. Expires November 4, 2009 [Page 2]
Internet-Draft EAP-AAAPAY May 2009
1. Introduction
This document defines a payload which can be securely transported by
an Extensible Authentication Method (EAP) method [RFC3748] that
carries arbitrary Diameter Attribute-Value Pairs (AVPs) [RFC3588].
While it may seem strange for EAP to encapsulate Authorization,
Authentication, and Accounting (AAA) messages, since AAA typically
encapsulates EAP, the security properties are different. In
particular, AAA data transported by EAP between the client and server
will be protected by an end-to-end security relationship. This
provides a secure channel for doing things like channel bindings
[RFC5056].
2. Terminology
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].
3. Overview and Requirements
Many EAP [RFC3748] methods have extensible properties that allow you
to embed arbitrary data within a secure channel. This channel is
secured using keys derived during the EAP authentication. These
channels vary in the properties that they provide, typically either
providing integrity protection or both confidentiality and integrity
protection.
In this document we define a payload format for encapsulating
Diameter AVPs [RFC3588], and via backwards compatability [RFC4005],
RADIUS TLVs [RFC2865]. We provide bindings for a variety of existing
EAP methods that would allow them to transport this data. One
specific application of this is to support EAP channel bindings
[RFC5056][I-D.clancy-emu-chbind].
The main goal is to provide the peer and server to exchange AAA
messages protected by an end-to-end security association. As such,
any EAP method transporting the AAA payloads defined in this document
MUST support integrity protection. To accomplish this, a method
supporting AAA payloads MUST perform mutual authentication and derive
session keys (i.e. MSK, etc), and during this derivation process
MUST derive a unique, cryptographically independent, fresh key for
protecting AAA payloads. Protocols SHOULD also support
confidentiality in addition to integrity protection. Confidentiality
Clancy, et al. Expires November 4, 2009 [Page 3]
Internet-Draft EAP-AAAPAY May 2009
is important for identity protection, as a variety of identities can
be passed over this channel.
4. AAA Payload Format
This section describes the formatting for the AAA Payloads. Each
payload consists of the following fields:
o Version, 1 octet
o Flags, 1 octet
o length(Session-ID), 2 octets
o Session-ID [I-D.ietf-eap-keying], arbitrary length
o One or more Diameter AVPs [RFC3588], arbitrary length
The version field is 1 octet. This documents defines version 0x01.
The flags field is 1 octet, and is the logical AND of the following
applicable values:
o 0x01: Validation Failed
o 0x02: Validation Inconclusive
o 0x04: Validation Successful
The validation flag fields are used by the EAP server to convey the
success of the consistency check to the EAP peer. These flags SHOULD
NOT be used in messages from the peer to server.
The Session-ID field is arbitrary length and is proceeded by its
2-octet length specified in network-byte order.
Following the Session-ID is an arbitrary number of Diameter AVPs.
AVPs already contain a length field internally, so they can be parsed
without additional information.
The payload can be graphically depicted as:
Clancy, et al. Expires November 4, 2009 [Page 4]
Internet-Draft EAP-AAAPAY May 2009
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version=0x01 | Flags | length(Session-ID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... Session-ID ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... Diameter AVP 1 ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... Diameter AVP N ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
5. Bindings for Existing EAP Methods
This section describes how binding tokens can be included in all
current EAP methods that support secure transport of arbitrary data.
Future EAP methods SHOULD describe how they can implement binding
tokens.
5.1. Generalized Pre-Shared Key (GPSK)
EAP-GPSK [I-D.ietf-emu-eap-gpsk] defines protected data payloads.
Use by GPSK simply requires instantiation of a new protected data
specifier (PData/Specifier):
o 0x0000002 (IANA-TBD): AAA Payload
5.2. Pre-Shared Key (PSK)
EAP-PSK [RFC4764] defines a protected channel. Use by PSK simply
requires instantiation of a new EXT_Type value:
o 0x01 (IANA-TBD): AAA Payload
Clancy, et al. Expires November 4, 2009 [Page 5]
Internet-Draft EAP-AAAPAY May 2009
5.3. Passord Authenticated Exchange (PAX)
EAP-PAX [RFC4746] defines an authenticated data exchange (ADE). Use
by PAX simply requires instantiation of a new ADE type:
o 0x04 (IANA-TBD): AAA Payload
5.4. Tunneled Transport Layer Security (TTLS)
EAP-TTLS [I-D.funk-eap-ttls-v0] uses Diameter Attribute-Value-Pairs
(AVPs) for its messaging. As such it natively supports transporting
AAA payloads. No protocol changes are necessary.
5.5. Flexible Authentication via Secure Tunneling (FAST)
EAP-FAST [RFC4851] uses Type-Length-Values (TLVs) for its messaging.
To embed binding tokens, a new TLV must be defined:
o 0x15 (IANA-TBD): AAA Payload
6. Security Considerations
Section 3 documented a variety of requirements for EAP methods to
transport these AAA payloads. They MUST support identity protection
of arbitrary payloads, and SHOULD support confidentiality. Each
method's security considerations section would detail how they
achieve those requirements.
The payload includes the EAP Session-ID field. This is to prevent
replay attacks. In particular, depending on how an EAP method
implements their secured channel, it may or may not be
cryptographically bound to the rest of the session. By explicitly
including the EAP Session-ID, we prevent replay attacks.
Implementations MUST verify the consistency of the Session-ID
received in the AAA payloads.
Certainly there are a whole host of issues surrounding the security
of what may be contained within the AAA payload format. If the
information being transported requires confidentiality, then the
method SHOULD support that. Otherwise sensitive data could be
disclosed.
7. IANA Considerations
We require registry from a variety of IANA repositories.
Clancy, et al. Expires November 4, 2009 [Page 6]
Internet-Draft EAP-AAAPAY May 2009
From "EAP-GPSK PData/Specifier":
o 0x0000002 (IANA-TBD): AAA Payload
From "EAP EXT_Type Numbers":
o 0x01 (IANA-TBD): AAA Payload
From "EAP-PAX ADE Type Namespace":
o 0x04 (IANA-TBD): AAA Payload
From "EAP-FAST TLV Types":
o 0x15 (IANA-TBD): AAA Payload
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
8.2. Informative References
[I-D.ietf-eap-keying]
Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
draft-ietf-eap-keying-22 (work in progress),
November 2007.
[I-D.ietf-emu-eap-gpsk]
Clancy, C. and H. Tschofenig, "EAP Generalized Pre-Shared
Key (EAP-GPSK) Method", draft-ietf-emu-eap-gpsk-17 (work
in progress), November 2008.
[I-D.funk-eap-ttls-v0]
Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS
Authentication Protocol Version 0 (EAP-TTLSv0)",
draft-funk-eap-ttls-v0-05 (work in progress), April 2008.
Clancy, et al. Expires November 4, 2009 [Page 7]
Internet-Draft EAP-AAAPAY May 2009
[I-D.clancy-emu-chbind]
Clancy, T. and K. Hoeper, "Channel Binding Support for EAP
Methods", Internet Draft draft-clancy-emu-chbind-02,
July 2008.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005,
August 2005.
[RFC4746] Clancy, T. and W. Arbaugh, "Extensible Authentication
Protocol (EAP) Password Authenticated Exchange", RFC 4746,
November 2006.
[RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A
Pre-Shared Key Extensible Authentication Protocol (EAP)
Method", RFC 4764, January 2007.
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
Flexible Authentication via Secure Tunneling Extensible
Authentication Protocol Method (EAP-FAST)", RFC 4851,
May 2007.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007.
Authors' Addresses
T. Charles Clancy
Laboratory for Telecommunications Sciences
US Department of Defense
College Park, MD
USA
Email: clancy@LTSnet.net
Clancy, et al. Expires November 4, 2009 [Page 8]
Internet-Draft EAP-AAAPAY May 2009
Avi Lior
Bridgewater Systems Corporation
303 Terry Fox Drive
Suite 100
Ottawa, Ontario K2K 3J1
Canada
Phone: +1 (613) 591-6655
Email: avi@bridgewatersystems.com
URI: http://www.bridgewatersystems.com/
Glen Zorn (editor)
Network Zen
1310 East Thomas Street
Seattle, Washington 98102
US
Phone: +1 (206) 377-9035
Email: gwz@net-zen.net
Clancy, et al. Expires November 4, 2009 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-23 14:42:59 |