Internet DRAFT - draft-paetow-abfab-credential-forward-delegate
draft-paetow-abfab-credential-forward-delegate
ABFAB S. Paetow
Internet-Draft Jisc
Intended status: Informational July 06, 2015
Expires: January 05, 2016
Application Bridging for Federated Access Beyond web (ABFAB) Credential
Forwarding and Delegation
draft-paetow-abfab-credential-forward-delegate-00
Abstract
A core use case of ABFAB-based authentication is access to remote
systems. In this and other use cases it is preferable that the same
identity initially used to gain access to the remote system is used
for further authentication sessions from the initial system onwards.
The current architecture and UI considerations require the use of
secure storage local to the system for any identities from that
system onwards. This document aims to explore alternate proposals
for the reuse of an identity configured on the initial ABFAB-enabled
client device by the use of credential forwarding or delegation in a
similar fashion to those used by other GSS-API mechanisms.
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 January 05, 2016.
Copyright Notice
Copyright (c) 2015 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.
Paetow Expires January 05, 2016 [Page 1]
Internet-Draft ABFAB Credential Forwarding July 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Credential Forwarding . . . . . . . . . . . . . . . . . . . . 3
6. Credential Delegation . . . . . . . . . . . . . . . . . . . . 3
7. Security Considerations . . . . . . . . . . . . . . . . . . . 3
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 3
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 4
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4
1. Introduction
One of the primary use cases for ABFAB-based authentication is the
use in HPC and grid computing systems. There currently exists no
mechanism to allow the delegation or forwarding on of the initial
identity configured for the system from the client device, therefore
it is only possible to either use ABFAB authentication to a single
system, or manually configure the chosen identity on the client
device.
This document intends to explore the possibilities of credential
delegation or credential forwarding in ABFAB in a similar fashion as
is currently available in other authentication mechanisms.
2. Conventions
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. Terminology
Various items of terminology used in the document are heavily
overloaded in that they mean a variety of different things to
different people. In an attempt to minimise this problem, this
section gives a brief description of the main items of terminology
used in order to aid a consistent understanding of this document.
o Identity: In this context, an identity is a credential given to a
user by a particular organisation with which they have an
association. A user may have multiple identities - potentially
multiple identities per organisation, and also across multiple
organisations. Each identity will consist of an NAI, alongside
other information that supports authentication. Note that in
other contexts the usual use of "identity" would match our use of
"user", whereas the usual use of "identifier" matches our use of
identity.
Paetow Expires January 05, 2016 [Page 2]
Internet-Draft ABFAB Credential Forwarding July 2015
o Service: The thing that the user is attempting to authenticate to
via ABFAB technology. See [I-D.ietf-abfab-usecases] for some
example ABFAB use cases. Also known as the Relying Party.
4. Context
When using the ABFAB architecture (see [I-D.ietf-abfab-arch]) to
perform federated authentication to some service, a user provides
identity information that they wish to use to authenticate to that
particular service. This identity information is provided for
authentication to that specific service only, therefore any further
authentication from that service to other ABFAB-based services is not
possible unless the identity information is also configured locally
on this particular service for use with other services.
This design is inadequate, particularly where the secure identity
storage on this particular service is ephemeral, or where the
security of the user's home directory cannot be guaranteed. In some
instances, this can be minimised, primarily with smart service
design, but there is simply no guarantee that this is the case
everywhere. Thus the solution may lie in credential forwarding or
delegation.
5. Credential Forwarding
TODO: Credential forwarding
6. Credential Delegation
TODO: Credential delegation
7. Security Considerations
TODO: Security considerations with credential forwarding and
delegation
8. Privacy Considerations
TODO: Privacy considerations with credential forwarding and
delegation
9. IANA Considerations
This document does not require actions by IANA.
10. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
Paetow Expires January 05, 2016 [Page 3]
Internet-Draft ABFAB Credential Forwarding July 2015
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R. and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[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", Internet-Draft draft-ietf-
abfab-arch-12, February 2014.
[I-D.ietf-abfab-usecases]
Smith, R., "Application Bridging for Federated Access
Beyond web (ABFAB) Use Cases", Internet-Draft draft-ietf-
abfab-usecases-05, September 2012.
[I-D.ietf-abfab-usability-ui-considerations]
Smith, R., "Application Bridging for Federated Access
Beyond web (ABFAB) Usability and User Interface
Considerations", Internet-Draft draft-ietf-abfab-
usability-ui-considerations-01, July 2014.
Appendix A. Change Log
Note to RFC Editor: if this document does not obsolete an existing
RFC, please remove this appendix before publication as an RFC.
Appendix B. Open Issues
Note to RFC Editor: please remove this appendix before publication as
an RFC.
Author's Address
Stefan Paetow
Jisc
Lumen House, Library Avenue
Didcot, OX11 0SG
United Kingdom
Phone: +44 1235 822125
Email: stefan.paetow@jisc.ac.uk
Paetow Expires January 05, 2016 [Page 4]