Internet DRAFT - draft-wdenniss-oauth-device-posture

draft-wdenniss-oauth-device-posture







OAuth Working Group                                           W. Denniss
Internet-Draft                                                    Google
Intended status: Standards Track                          KM. McGuinness
Expires: May 17, 2018                                               Okta
                                                              J. Bradley
                                                                  Yubico
                                                       November 13, 2017


                    OAuth 2.0 Device Posture Signals
                 draft-wdenniss-oauth-device-posture-01

Abstract

   Enterprise and security focused OAuth providers typically want
   additional signals to confirm user presence when users return to
   previously authorized apps.  Rather than requiring a full
   reauthentication, or require enrollment in a mobile device management
   solution, some authorization servers may be willing to accept device
   posture signals from the app, like the fact that device has a lock
   screen, as confirmation of user presence.  This document details how
   OAuth native app clients can communicate device posture signals to
   OAuth providers.

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 May 17, 2018.

Copyright Notice

   Copyright (c) 2017 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



Denniss, et al.           Expires May 17, 2018                  [Page 1]

Internet-Draft      OAuth 2.0 Device Posture Signals       November 2017


   (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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Notational Conventions  . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Device Posture Signal Dictionary  . . . . . . . . . . . . . .   3
   5.  Authorization Request Device Posture Hint . . . . . . . . . .   5
   6.  Token Endpoint Device Posture Enforcement . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
     7.1.  Device Posture Scope  . . . . . . . . . . . . . . . . . .   6
     7.2.  Spoofed Devices . . . . . . . . . . . . . . . . . . . . .   6
     7.3.  App Trustworthiness . . . . . . . . . . . . . . . . . . .   6
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  OAuth Parameters Registration . . . . . . . . . . . . . .   7
       8.1.1.  Registry Contents . . . . . . . . . . . . . . . . . .   7
     8.2.  OAuth Extensions Error Registration . . . . . . . . . . .   7
       8.2.1.  Registry Contents . . . . . . . . . . . . . . . . . .   7
     8.3.  Device Posture Keys Registry  . . . . . . . . . . . . . .   7
       8.3.1.  Registration Template . . . . . . . . . . . . . . . .   8
       8.3.2.  Initial Registry Contents . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Users who follow strong security practices on their devices - such as
   configuring screen locks, and not enabling admin privileges (commonly
   known as "rooting" or "jailbreaking") - shouldn't need to
   reauthenticate frequently to the individual apps on their device.

   This specification details how apps can send device posture signals
   to the OAuth Token Endpoint, enabling it to enforce device policy
   compliance, and avoid the need for reauthentication in some cases.

   It is designed to provide a mechanism for honest apps to communicate
   device posture.  By itself it doesn't protect against malicious




Denniss, et al.           Expires May 17, 2018                  [Page 2]

Internet-Draft      OAuth 2.0 Device Posture Signals       November 2017


   users, dishonest apps, or compromised devices, but the signal format
   described could carry signals that do.

2.  Notational Conventions

   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 Key
   words for use in RFCs to Indicate Requirement Levels [RFC2119].  If
   these words are used without being spelled in uppercase then they are
   to be interpreted with their normal natural language meanings.

3.  Terminology

   In addition to the terms defined in referenced specifications, this
   document uses the following terms:

   MDM
      Mobile Device Management.

   EMM
      Enterprise Mobility Management.

4.  Device Posture Signal Dictionary

   The device posture is a dictionary of signals asserted by the app
   about the device.  The structure is send as an added parameter in
   several places during the OAuth flow, as documented in the subsequent
   sections.

   All device posture keys are OPTIONAL and MUST only be set when the
   attribute can be obtained by the app.  The standard attribute keys
   are as follows:

   screen_lock
      Boolean.  True if the device has a screen lock, such as a pin,
      pattern biometric, etc.

   root_privileges
      Boolean.  True if user apps can access root device privileges.
      For mobile operating systems, known as "jailbreaking" on iOS and
      "rooting" on Android.

   full_disk_encryption
      Boolean.  True if data stored on the device is fully encrypted at
      rest.

   device_id



Denniss, et al.           Expires May 17, 2018                  [Page 3]

Internet-Draft      OAuth 2.0 Device Posture Signals       November 2017


      String.  A unique identifier for the device.

   device_os
      String.  The name of the operating system running on the device
      such as "iOS" or "Android".

   device_os_version
      String.  The current version of the operating system.

   device_vendor
      String.  The vendor of the device such as "Apple" or "Google".

   device_model
      String.  The model of the device such as "iPhone X" or "Pixel 2".

   device_attestation
      Dictionary.  An attestation from the operating system, containing
      a signed-statement about the device and/or the app.  The format is
      a dictionary, the specifics of which depends on the operating
      system.

   app_id
      String.  The platform-specific identifier (URI) for the
      application.  For Android, the format of the URI is android:apk-
      key-hash:<hash-of-apk-signing-cert>.  For iOS, the format of URI
      is ios:bundle-id:<ios-bundle-id-of-app>.

   app_managed
      Boolean.  True if the app is managed by a MDM/EMM system.

   An example device posture dictionary:

   {
       "screen_lock": true,
       "root_privileges": false,
       "full_disk_encryption": true,
       "device_id": "6bdde1e8-0667-40f9-9993-16aa52ee6b38",
       "device_os": "iOS",
       "device_os_version": "11.1",
       "device_vendor": "Apple",
       "device_model": "iPhone X",
       "app_id": "ios:bundle-id:com.example.myapp",
       "app_managed": false
   }







Denniss, et al.           Expires May 17, 2018                  [Page 4]

Internet-Draft      OAuth 2.0 Device Posture Signals       November 2017


5.  Authorization Request Device Posture Hint

   Clients MAY send the device posture signal dictionary to the
   authorization server in the authorization request.  These signals,
   except for those that are signed and bound to the device are
   susceptible to client-side modification by end-users.  While
   untrusted, such signals can still be used as hints by the
   authorization server to present a better user experience, like
   informing the user they need a lock screen.

   Error encountered during authorization can be displayed to the user
   in the browser making this a more user friendly way to instruct the
   user on how to move their device into conformance.  The token
   endpoint (on which errors are less user-friendly as there's no user
   agent), can then enforce the restrictions per Section 6.

   The following parameters are added to the OAuth 2.0 Authorization
   Request or the OpenID Connect Authorization Request:

   device_posture_hint
      JSON String.  URL-encoded JSON dictionary, contains the Device
      Posture Signals defined in Section 4.

   A AS receving device_posture_hint may pass the value on to upstream
   OpenID Connect IDP using the same paramater to enable the
   Authentication Server to make policy decisions.

6.  Token Endpoint Device Posture Enforcement

   Clients that follow this specification MUST send the device posture
   signals on every request to the token endpoint.

   Token Endpoints SHOULD verify that the posture conforms to their
   requirements and act accordingly.

   The following parameters are added to all requests to the Token
   Endpoint:

   device_posture
      JSON String.  URL-encoded JSON dictionary, contains the Device
      Posture Signals defined in Section 4.

   The app MUST obtain fresh device posture information before every
   request to the Token Endpoint, and MUST NOT include stale information
   (rather, it should drop any signals it cannot freshly obtain).

   For token refresh requests, where the device posture has been
   previously communicated, if an attribute is missing, the Token



Denniss, et al.           Expires May 17, 2018                  [Page 5]

Internet-Draft      OAuth 2.0 Device Posture Signals       November 2017


   Endpoint may choose to use the previous value, based on it's own
   policy and freshness requirements.

   If the policy does not meet requirements, the Token Endpoint SHOULD
   return the following error code:

   device_posture_invalid
      Error indicating that the device posture does not meet
      requirements.  The error description SHOULD contain details on why
      this is is the case.

7.  Security Considerations

7.1.  Device Posture Scope

   This specification is designed to help authorization servers enforce
   security policy (like requiring a lock screen) on end-users.  The
   intent is to enforce restrictions on honest users, to force them to
   follow security practices set out by the authorization server.  By
   itself, it offers no protection against malicious users, dishonest
   apps, or compromised devices.

   Combined with other technologies like device-based attestations and
   token binding may enable such protection, and this specification
   could be used to transmit secure signals, but that topic is out of
   scope for this specification.

7.2.  Spoofed Devices

   It is possible to at a device level completely spoof the device
   posture.  Even statements signed by the operating system are
   vulnerable to spoofing, as it's possible a statement from the real
   device can be replayed on a spoofed device, unless such statements
   include a binding to the device itself.  Per Section 7.1, this topic
   is out of scope for this specification.

7.3.  App Trustworthiness

   This specification is designed to allow trusted apps to report device
   posture to the authorization server to help the server enforce
   security policy on end-users.  It does not by itself force apps to be
   honest, or genuine.  Genuine apps (i.e. apps not lying about their
   client ID) might be dishonest about the device posture, and apps that
   are normally honest, could be spoofed, unless anti-spoofing
   countermeasures that are out of scope of this specification are
   employed.





Denniss, et al.           Expires May 17, 2018                  [Page 6]

Internet-Draft      OAuth 2.0 Device Posture Signals       November 2017


8.  IANA Considerations

8.1.  OAuth Parameters Registration

   This specification registers the following value in the IANA "OAuth
   Parameters" registry [IANA.OAuth.Parameters] established by
   [RFC6749].

8.1.1.  Registry Contents

   o  Parameter name: device_posture_hint
   o  Parameter usage location: authorization request
   o  Change controller: IESG
   o  Specification document(s): Section 5 of [[ this specification ]]

   o  Parameter name: device_posture
   o  Parameter usage location: token request
   o  Change controller: IESG
   o  Specification document(s): Section 6 of [[ this specification ]]

8.2.  OAuth Extensions Error Registration

   This specification registers the following error in the IANA "OAuth
   Extensions Error Registry" [IANA.OAuth.Parameters] established by
   [RFC6749].

8.2.1.  Registry Contents

   o  Error name: device_posture_invalid
   o  Error usage location: authorization response, token error response
   o  Related protocol extension: resource parameter
   o  Change controller: IESG
   o  Specification document(s): Section 6 of [[ this specification ]]

8.3.  Device Posture Keys Registry

   This specification establishes the IANA "Device Posture Keys"
   registry for Device Posture Dictionary keys.  The registry records
   the Device Posture key and a reference to the specification that
   defines it.  This specification registers the Device Posture keys
   defined in Section 4.

   Keys are registered on an Expert Review [RFC5226] basis after a
   three-week review period on the oauth-reg-review@ietf.org mailing
   list, on the advice of one or more Designated Experts.






Denniss, et al.           Expires May 17, 2018                  [Page 7]

Internet-Draft      OAuth 2.0 Device Posture Signals       November 2017


   Registration requests sent to the mailing list for review should use
   an appropriate subject (e.g., "Request to register Device Posture
   Key: screen_lock").

   Within the review period, the Designated Experts will either approve
   or deny the registration request, communicating this decision to the
   review list and IANA.  Denials should include an explanation and, if
   applicable, suggestions as to how to make the request successful.
   Registration requests that are undetermined for a period longer than
   21 days can be brought to the IESG's attention (using the
   iesg@ietf.org mailing list) for resolution.

   Criteria that should be applied by the Designated Experts includes
   determining whether the proposed registration duplicates existing
   functionality, whether it is likely to be of general applicability or
   whether it is useful only for a single application, whether the value
   is actually being used, and whether the registration description is
   clear.

   IANA must only accept registry updates from the Designated Experts
   and should direct all requests for registration to the review mailing
   list.

   It is suggested that the same Designated Experts evaluate these
   registration requests as those who evaluate registration requests for
   the IANA "OAuth Parameters" registry [IANA.OAuth.Parameters].

8.3.1.  Registration Template

   Device Posture Signal Key:
      The key name requested (e.g., "screen_lock").  Names may not match
      other registered names in a case-insensitive manner unless the
      Designated Experts state that there is a compelling reason to
      allow an exception.
   Device Posture Signal Key Description:
      Brief description of the device posture signal (e.g., "Screen lock
      active").
   Change Controller:
      For Standards Track RFCs, state "IESG".  For others, give the name
      of the responsible party.  Other details (e.g., postal address,
      email address, home page URI) may also be included.
   Specification Document(s):
      Reference to the document or documents that specify the parameter,
      preferably including URIs that can be used to retrieve copies of
      the documents.  An indication of the relevant sections may also be
      included but is not required.





Denniss, et al.           Expires May 17, 2018                  [Page 8]

Internet-Draft      OAuth 2.0 Device Posture Signals       November 2017


8.3.2.  Initial Registry Contents

   o  Device Posture Signal Key: "screen_lock"
   o  Device Posture Signal Key Description: Boolean. 'true' when the
      device has a screen lock enabled.
   o  Change Controller: IESG
   o  Specification Document(s): Section 4 of [[ this specification ]]

   o  Device Posture Signal Key: "root_privileges"
   o  Device Posture Signal Key Description: Boolean.  True if user apps
      can access root device privileges.
   o  Change Controller: IESG
   o  Specification Document(s): Section 4 of [[ this specification ]]

   o  Device Posture Signal Key: "full_disk_encryption"
   o  Device Posture Signal Key Description: Boolean.  True if data
      stored on the device is fully encrypted at rest.
   o  Change Controller: IESG
   o  Specification Document(s): Section 4 of [[ this specification ]]

   o  Device Posture Signal Key: "device_id"
   o  Device Posture Signal Key Description: String.  A unique
      identifier for the device.
   o  Change Controller: IESG
   o  Specification Document(s): Section 4 of [[ this specification ]]

   o  Device Posture Signal Key: "device_os"
   o  Device Posture Signal Key Description: String.  The name of the
      operating system running on the device such as "iOS" or "Android".
   o  Change Controller: IESG
   o  Specification Document(s): Section 4 of [[ this specification ]]

   o  Device Posture Signal Key: "device_os_version"
   o  Device Posture Signal Key Description: String.  The current
      version of the operating system.
   o  Change Controller: IESG
   o  Specification Document(s): Section 4 of [[ this specification ]]

   o  Device Posture Signal Key: "device_vendor"
   o  Device Posture Signal Key Description: String.  The vendor of the
      device such as "Apple or "Google".
   o  Change Controller: IESG
   o  Specification Document(s): Section 4 of [[ this specification ]]

   o  Device Posture Signal Key: "device_model"
   o  Device Posture Signal Key Description: String.  The model of the
      device such as "iPhone X" or "Pixel 2"
   o  Change Controller: IESG



Denniss, et al.           Expires May 17, 2018                  [Page 9]

Internet-Draft      OAuth 2.0 Device Posture Signals       November 2017


   o  Specification Document(s): Section 4 of [[ this specification ]]

   o  Device Posture Signal Key: "device_attestation"
   o  Device Posture Signal Key Description: Dictionary.  An attestation
      from the operating system, containing a signed-statement about the
      device and/or the app.
   o  Change Controller: IESG
   o  Specification Document(s): Section 4 of [[ this specification ]]

   o  Device Posture Signal Key: "app_id"
   o  Device Posture Signal Key Description: String.  The platform-
      specific identifier (URI) for the application.  For Android, the
      format of the URI is android:apk-key-hash:<hash-of-apk-signing-
      cert>.  For iOS, the format of URI is ios:bundle-id:<ios-bundle-
      id-of-app>.
   o  Change Controller: IESG
   o  Specification Document(s): Section 4 of [[ this specification ]]

   o  Device Posture Signal Key: "app_managed"
   o  Device Posture Signal Key Description: Boolean.  True if the app
      is managed by a MDM/EMM system.
   o  Change Controller: IESG
   o  Specification Document(s): Section 4 of [[ this specification ]]

9.  References

9.1.  Normative References

   [IANA.OAuth.Parameters]
              IANA, "OAuth Parameters",
              <http://www.iana.org/assignments/oauth-parameters>.

   [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>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <https://www.rfc-editor.org/info/rfc5226>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/info/rfc6749>.






Denniss, et al.           Expires May 17, 2018                 [Page 10]

Internet-Draft      OAuth 2.0 Device Posture Signals       November 2017


9.2.  Informative References

   [RFC6819]  Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
              Threat Model and Security Considerations", RFC 6819,
              DOI 10.17487/RFC6819, January 2013,
              <https://www.rfc-editor.org/info/rfc6819>.

Appendix A.  Acknowledgements

   The following individuals contributed ideas, feedback, and wording
   that shaped and formed the final specification:

   Eric Sachs, John Bradley, and Andy Zmolek.

Authors' Addresses

   William Denniss
   Google
   1600 Amphitheatre Pkwy
   Mountain View, CA  94043
   USA

   Phone: +1 650-253-0000
   Email: wdenniss@google.com
   URI:   http://google.com/


   Karl McGuinness
   Okta
   301 Brannan St.
   San Francisco, CA  94107
   USA

   Email: kmcguinness@okta.com
   URI:   https://www.okta.com/


   John Bradley
   Yubico
   530 Lytton Ave, Suite 301
   Palo Alto, CA  94301
   USA

   Phone: +1 202-630-5272
   Email: ietf@ve7jtb.com
   URI:   https://www.thread-safe.com/





Denniss, et al.           Expires May 17, 2018                 [Page 11]