Ephemeral keying for ABFAB
draft-linus-abfab-ephemeral-keying-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Linus Nordberg , Josh Howlett | ||
| Last updated | 2014-02-14 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-linus-abfab-ephemeral-keying-00
ABFAB L. Nordberg
Internet-Draft NORDUnet
Intended status: Informational J. Howlett
Expires: August 17, 2014 JANET(UK)
February 13, 2014
Ephemeral keying for ABFAB
draft-linus-abfab-ephemeral-keying-00
Abstract
This document describes how EAP-GSS provides forward secrecy by
encrypting each session in an ephemeral key generated in the initial
state of the context establishment. This Diffie-Hellman key is
shared by the initiator (EAP peer) and acceptor (EAP authenticator).
The goal is to stop a passive attacker with access to the traffic
between an ABFAB user and the service she uses (Relying Party), from
getting access to key material and information linkable to the user
or from being able to fingerprint the user.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 17, 2014.
Copyright Notice
Copyright (c) 2014 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
Nordberg & Howlett Expires August 17, 2014 [Page 1]
Internet-Draft Ephemeral keying for ABFAB February 2014
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Information potentially accessible to a passive observer . . . 4
2.1. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. EAP method . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. GSS-API data . . . . . . . . . . . . . . . . . . . . . . . 4
3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Why do this at the GSS-EAP layer . . . . . . . . . . . . . 6
4. Keying algorithm . . . . . . . . . . . . . . . . . . . . . . . 7
5. Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Open questions . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security considerations . . . . . . . . . . . . . . . . . . . 10
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Nordberg & Howlett Expires August 17, 2014 [Page 2]
Internet-Draft Ephemeral keying for ABFAB February 2014
1. Introduction
The ABFAB architecture [I-D.ietf-abfab-arch] defines a GSS-API
mechanism for the Extensible Authentication Protocol [RFC7055]. This
mechanism provides support for the security services offered by the
GSS-API, including the confidentiality of context tokens. This
confidentiality service is available once a GSS context has been
negotiated successfully between the initiator and acceptor.
However there is a possibility that a passive observer could extract
information from this negotiation that could potentially compromise
aspects of the confidentiality of the context tokens and/or the
privacy of the initiator and/or acceptor.
This document defines an extension to [RFC7055] to deny a passive
observer access to this information by encrypting the tokens used to
establish the GSS context.
Nordberg & Howlett Expires August 17, 2014 [Page 3]
Internet-Draft Ephemeral keying for ABFAB February 2014
2. Information potentially accessible to a passive observer
This section describes the information available to a passive
observer of an [RFC7055] negotiation between an initiator and
acceptor, working from the lowest layers of the protocol stack
upwards.
2.1. RADIUS
The realm component of the NAI [RFC4282] is generally exposed. While
the user name component of the NAI is easily anonymised, the realm
(which effectively names the user's identity provider (IdP)) will
provide a strong indication of the organisational affiliation of a
user.
In the event that RADIUS/UDP is being used instead of RADIUS/TLS,
intermediate proxies between the acceptor and IdP have access to the
EAP MSK. Knowledge of the MSK could facilitate the compromise of the
GSS context, which is derived from this key, potentially allowing
decryption of the GSS session.
2.2. EAP method
The EAP methods most commonly used with [RFC7055] use X.509 server
certificates to authenticate the IdP. This certificate will include
information identifying the IdP's server.
A passive observer may also be able to fingerprint the EAP
implementation [FIXME].
2.3. GSS-API data
A variety of information is available at the GSS-API layer.
o The acceptor name is carried in name requests and responses during
the initial phase. This can be used for fingerprinting users
since it indicates what service is requested and supplied. In
settings where the endpoint's IP addresses and other identifying
information don't link the user to the service, exposing the
acceptor name is detrimental to privacy.
o GSS channel bindings are also available in the extensions state;
these bindings typically identify the acceptor to the initiator.
o The currently defined flags leak information about which
application protocol is being used and pose a threat to user
privacy. Future flags might increase this threat.
Nordberg & Howlett Expires August 17, 2014 [Page 4]
Internet-Draft Ephemeral keying for ABFAB February 2014
o Finally the mechanism MIC is also exposed and error subtokens are
also exposed [FIXME].
Nordberg & Howlett Expires August 17, 2014 [Page 5]
Internet-Draft Ephemeral keying for ABFAB February 2014
3. Solution
Generate a Diffie-Hellman key in the initial state of the context
establishment and use it to encrypt other context tokens. Note that
the DH key, shared by initiator and acceptor, is unique per GSS-API
session, not per context token. [Elaborate on why?]
[describe where in initial the DH key exchange happens and how; point
at general description? copy from existing standard?]
[ describe how we signal algorithm and key size ]
[ describe the use of a nonce/sequence number for temporality, either
in the key or in the payload, covered by the MIC and verified by the
other end - mitigates replay, reflection and reordering attacks ]
[ describe how we derive a symmetric key from the DH key and encrypt
the context token (perhaps in a GSS "wrap token"?) ]
[ describe how to mix in the DH key with the MSK to form the CRK
(7055 sect 6) - this will make a MITM kexing with both ends unable to
create a MIC which validates properly (and a MITM relaying DH kex
will not know the key and thus not the CRK) ]
3.1. Why do this at the GSS-EAP layer
Using a short lived key for providing confidentiality between an
ABFAB client and the IdP could arguably be done at the EAP layer
rather than at the GSS-API layer. A general solution for EAP would
give better protocol reuse.
EAP methods run between the EAP peer and server. A Diffie-Hellman
key exchange between these endpoints can not start with the first
message sent from the client since the client doesn't talk to the EAP
server (the IdP) directly and can not be helped with doing that until
the EAP authenticator knows where the IdP is to be found. Most of
the mentioned leaks at the GSS-API layer would thus still be present
in this solution.
[ maybe expand on how TEAP [draft-ietf-emu-eap-tunnel-method] could
solve the problem of AAA proxies learning the MSK, impersonating the
RP ]
Nordberg & Howlett Expires August 17, 2014 [Page 6]
Internet-Draft Ephemeral keying for ABFAB February 2014
4. Keying algorithm
This section defines an algorithm, based on the Diffie-Hellman
protocol, enabling the initiator and acceptor to negotiate a shared
key during the initial phase of the GSS context establishment. This
key is used to encrypt all subsequent context tokens. The key is
unique per GSS-API session, and is not rotated for each successive
context token. [Elaborate on why not?]
Nordberg & Howlett Expires August 17, 2014 [Page 7]
Internet-Draft Ephemeral keying for ABFAB February 2014
5. Costs
o This will cost FIXME extra round trips.
o [No new GSS mech. Thus no complexity cost of picking the right
one.]
Nordberg & Howlett Expires August 17, 2014 [Page 8]
Internet-Draft Ephemeral keying for ABFAB February 2014
6. Open questions
o Should we make the ephemeral keying and encryption optional?
Might have to - asking the list about breaking backward
compatibility.
o Bid down attacks - detect, prevent
Fascinating idea from Sam: 6067 CB implementing 5056 CB could
detect MITM before end of extension state (MIC).
o Include the nonce/sequence number in tokens or fold it into the
key?
Nordberg & Howlett Expires August 17, 2014 [Page 9]
Internet-Draft Ephemeral keying for ABFAB February 2014
7. Security considerations
TBD
Nordberg & Howlett Expires August 17, 2014 [Page 10]
Internet-Draft Ephemeral keying for ABFAB February 2014
8. Contributors
The whole idea of adding ephemeral keys to ABFAB was suggested by Sam
Hartman who also contributed substantial ideas and discussions on
this subject.
Nordberg & Howlett Expires August 17, 2014 [Page 11]
Internet-Draft Ephemeral keying for ABFAB February 2014
9. Normative References
[I-D.ietf-abfab-arch]
Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J.
Schaad, "Application Bridging for Federated Access Beyond
Web (ABFAB) Architecture", draft-ietf-abfab-arch-12 (work
in progress), February 2014.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
[RFC7055] Hartman, S. and J. Howlett, "A GSS-API Mechanism for the
Extensible Authentication Protocol", RFC 7055,
December 2013.
Nordberg & Howlett Expires August 17, 2014 [Page 12]
Internet-Draft Ephemeral keying for ABFAB February 2014
Authors' Addresses
Linus Nordberg
NORDUnet
Email: linus@nordu.net
Josh Howlett
JANET(UK)
Email: Josh.Howlett@ja.net
Nordberg & Howlett Expires August 17, 2014 [Page 13]