Internet DRAFT - draft-schaad-cnf-cwt-id
draft-schaad-cnf-cwt-id
Network Working Group J. Schaad
Internet-Draft August Cellars
Intended status: Experimental October 22, 2018
Expires: April 25, 2019
Use of a CWT identifier as a Confirmation Method
draft-schaad-cnf-cwt-id-00
Abstract
TBD
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 https://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 April 25, 2019.
Copyright Notice
Copyright (c) 2018 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
(https://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.
Schaad Expires April 25, 2019 [Page 1]
Internet-Draft CWT ID Confirmation October 2018
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. CWT Id Confirmation Method . . . . . . . . . . . . . . . . . 3
4. CWT Id in AS Response . . . . . . . . . . . . . . . . . . . . 3
5. Processing Rules for the Issuer of a CWT Id Confirmation
Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Processing Rules for the CWT Id Confirmation Method . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . 4
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
9. Normative References . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
In many cases an authorization in the form of a COSE Web Token (CWT)
[RFC8392] will be issued in the ACE OAuth [I-D.ietf-ace-oauth-authz]
framework with a minimal set of privileges and a Proof-of-Possession
claim [I-D.ietf-ace-cwt-proof-of-possession]. It may then become
necessary to issue a new token for a shorter period with more
capabilities, but use the same information for validation. In these
cases it makes sense to issue a new authorization token which refers
the the first token to provide the additional capabilities. This
document defines a new confirmation type that allows this type of
referencing to be done.
This differs from the refresh token in that the new token will be
limited to the duration of the existing CWT, while a new POP CWT
would be issued when using a refresh token.
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Terminology
o "Relying Party" is used in this document to refer to the party
which is relying on the contents of a CWT in order to make a
security decision. In other OAuth documents, this is normally
referred to as the XXXXXX.
Schaad Expires April 25, 2019 [Page 2]
Internet-Draft CWT ID Confirmation October 2018
o "Referenced CWT" is used to denote the CWT which is referred to or
referenced by a referencing CWT. The referenced CWT has a
confirmation type with the POP keying information in it.
o "Referencing CWT" is used to denote the CWT which is making a
reference to a second CWT. The referencing CWT contains the
confirmation type defined in this document.
3. CWT Id Confirmation Method
The CWT Id confirmation method is identified by TBD1 in the 'cnf'
element (defined in [I-D.ietf-ace-cwt-proof-of-possession]. For use
in documentation the string value of 'cwtid' is to be used to refer
to this confirmation type.
The CWT Id confirmation method uses the type of CBOR map and has the
following fields:
o Issuer is an optional field in the map. If present the issuer
field contains the 'iss' field of CWT which is being referenced.
If absent, the issuer is the same entity which issued the
referencing CWT. When encoded, this field uses TBD2 as the map
key.
o CWT Id is a required field in the map. The field contains the
'cwtid' field of the referenced CWT. When encoded, this field
uses TBD3 as the map key.
An example of what this would look like is:
/ cnf /: {
/ cwtid /: 'CWTID 1234',
/ iss /: "Entry-Level AS"
}
4. CWT Id in AS Response
Since the CWT Id is currently only provided to the RS as part of the
token, for an AS which supports this option the CWT Id additionally
needs to be provided to the Client. This document therefore defines
two new fields to go into C-AS response messages:
"iss" provides the issuer name of the CWT. This field is only
present for an AS which would allow a second AS to refer to the
CWT.
"cwtid" contains the CWT Id for the issued token.
Schaad Expires April 25, 2019 [Page 3]
Internet-Draft CWT ID Confirmation October 2018
5. Processing Rules for the Issuer of a CWT Id Confirmation Method
When an AS is going to issue a CWT it MUST perform the following
steps or their equivalent:
1. If the issued CWT will refer to a CWT issued by a different AS,
the issuing AS MUST be configured to permit this.
2. The AS MUST validate that the entity for which this CWT is being
issued for is the same entity that is the subject of the
referenced CWT. This can be done by causing the client to
perform a POP operation with the referenced CWTs POP key
information or by querying the AS which issued the referenced
CWT. If the same AS is being used for both CWTs, then the AS can
consult a database of clients and CWTs to check for identity
matching.
3. The issued CWT should refer to the original POP CWT. The chain
of trust SHOULD NOT be transitive through another CWT.
6. Processing Rules for the CWT Id Confirmation Method
When a relying party receives a referencing CWT it MUST perform the
following steps or their equivalent as part of making a security
decision:
1. The referencing CWT MUST have the authentication checked on it.
If the authentication fails, the CWT MUST be rejected.
2. If the CWT Id confirmation type contains an issuer field,
configuration information MUST be checked that the referencing
CWT issuer is permitted to use the referenced CWT issuer. If the
reference is not permitted, then the CWT MUST be rejected.
3. If the referenced CWT is expired, the referencing CWT MUST be
rejected.
4. The claims in the referenced CWT are copied from the referenced
CWT to the referencing CWT if the claim does not exist in the
referencing CWT.
5. The modified CWT is then processed in a normal manner.
7. Security Considerations
As the security of the set of CWTs is going rest on the underlying
POP CWT, loss of the key will allow any CWT which references the
Schaad Expires April 25, 2019 [Page 4]
Internet-Draft CWT ID Confirmation October 2018
orignal CWT to be used by a third party. All entities which have the
secret portion of the key need to protect that portion of the key.
The use of this feature assumes a specific model of evaluating the
rules for access control. Specifically, it assumes that if there are
multiple access tokens, satisfying the conditions for any of the
tokens means that access is going to be granted. This model is in
contrast to one where if any of the access tokens was a deny, then
access to to the resource would be denied.
8. IANA Considerations
There are some items that need to be registered. Figure out what
they are and put them here.
9. Normative References
[I-D.ietf-ace-cwt-proof-of-possession]
Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of-
possession-03 (work in progress), June 2018.
[I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-16
(work in progress), October 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>.
Author's Address
Schaad Expires April 25, 2019 [Page 5]
Internet-Draft CWT ID Confirmation October 2018
Jim Schaad
August Cellars
Email: ietf@augustcellars.com
Schaad Expires April 25, 2019 [Page 6]
