Internet DRAFT - draft-linus-abfab-ephemeral-keying
draft-linus-abfab-ephemeral-keying
ABFAB L. Nordberg
Internet-Draft NORDUnet
Intended status: Informational J. Howlett
Expires: September 7, 2014 JANET(UK)
March 06, 2014
Ephemeral keying for ABFAB
draft-linus-abfab-ephemeral-keying-01
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 September 7, 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 September 7, 2014 [Page 1]
Internet-Draft Ephemeral keying for ABFAB March 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Information potentially accessible to a passive observer . . 2
2.1. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. EAP method . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. GSS-API data . . . . . . . . . . . . . . . . . . . . . . 3
3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Why do this at the GSS-EAP layer . . . . . . . . . . . . 4
4. Keying algorithm . . . . . . . . . . . . . . . . . . . . . . 5
5. Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Open questions . . . . . . . . . . . . . . . . . . . . . . . 5
7. Security considerations . . . . . . . . . . . . . . . . . . . 5
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 5
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5
10. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
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.
2. Information potentially accessible to a passive observer
This section describes the information available to a passive
observer of an [I-D.ietf-abfab-arch] authentication, working from the
lowest layers of the protocol stack upwards.
Nordberg & Howlett Expires September 7, 2014 [Page 2]
Internet-Draft Ephemeral keying for ABFAB March 2014
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, not
only do the intermediate proxies between the acceptor and the IdP
have access to the EAP MSK but a passive observer does too.
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].
In cases where a TLS-based EAP method is used, a passive observer may
be able to fingerprint the client based on TLS session resumption,
for example as described in [RFC5077] section 5.8.
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.
o Finally the mechanism MIC is also exposed and error subtokens are
also exposed [FIXME].
Nordberg & Howlett Expires September 7, 2014 [Page 3]
Internet-Draft Ephemeral keying for ABFAB March 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 September 7, 2014 [Page 4]
Internet-Draft Ephemeral keying for ABFAB March 2014
An alternative place to protect ABFAB authentication with a short
lived key would be in the application level protocol. While some
applications are using protocols already able to protect the GSS-API
traffic using a TLS session with an ephemeral key (XMPP, IMAP, SMTP)
it's not mandatory to use such a tunnel. Other applications use
protocols which might be hard to protect in a tunnel (NFS, SSH).
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?]
5. Costs
o This will cost FIXME extra round trips.
o [No new GSS mech. Thus no complexity cost of picking the right
one.]
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?
7. Security considerations
TBD
8. IANA considerations
TBD.
9. Contributors
Nordberg & Howlett Expires September 7, 2014 [Page 5]
Internet-Draft Ephemeral keying for ABFAB March 2014
The whole idea of adding ephemeral keys to ABFAB was suggested by Sam
Hartman who also contributed substantial ideas and discussions on
this subject.
Jim Schaad has made several valuable comments with corrections and
suggestions.
10. 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.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008.
[RFC7055] Hartman, S. and J. Howlett, "A GSS-API Mechanism for the
Extensible Authentication Protocol", RFC 7055, December
2013.
Authors' Addresses
Linus Nordberg
NORDUnet
Email: linus@nordu.net
Josh Howlett
JANET(UK)
Email: Josh.Howlett@ja.net
Nordberg & Howlett Expires September 7, 2014 [Page 6]
