Internet DRAFT - draft-vanrein-eap-kerberos

draft-vanrein-eap-kerberos







Network Working Group                                        R. Van Rein
Internet-Draft                                                 ARPA2.net
Intended status: Standards Track                          March 13, 2016
Expires: September 14, 2016


   Kerberos in the Extensible Authentication Protocol (EAP-Kerberos)
                     draft-vanrein-eap-kerberos-00

Abstract

   This specification permits Kerberos authentication as part of the
   EAP.  To support identity bootstrapping during network logon, the
   preceding acquisition of tickets may also be passed through this EAP
   mechanism.

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 14, 2016.

Copyright Notice

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




Van Rein               Expires September 14, 2016               [Page 1]

Internet-Draft                EAP-Kerberos                    March 2016


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Inner and Outer Identities  . . . . . . . . . . . . . . . . .   3
   3.  Transporting Kerberos Frames over EAP . . . . . . . . . . . .   4
     3.1.  EAP-Kerberos as a Flow of Kerberos Frames . . . . . . . .   4
     3.2.  Format of a Kerberos Frame  . . . . . . . . . . . . . . .   4
     3.3.  Encapsulation of Kerberos Frames in EAP . . . . . . . . .   5
   4.  Component Support for EAP-Kerberos  . . . . . . . . . . . . .   6
     4.1.  Peer Support for EAP-Kerberos . . . . . . . . . . . . . .   6
     4.2.  Authenticator Support for EAP-Kerberos  . . . . . . . . .   7
     4.3.  Backend Support for EAP-Kerberos  . . . . . . . . . . . .   7
   5.  Established Master Key  . . . . . . . . . . . . . . . . . . .   9
   6.  Efficiency Considerations . . . . . . . . . . . . . . . . . .   9
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  10
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  11
     10.2.  Informative References . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   EAP, or the Extensible Authentication Protocol, is a pluggable
   mechanism for the control of network or service access by users.  It
   is usually communicated with users during a login phase of PPP or
   802.1x, and passed on to backend servers in a RADIUS attribute
   [Section 5.1 of [RFC2865]] or Diameter AVP [Section 8.14 of
   [RFC6733]] set aside for EAP.

   Although often used with password-based policies, EAP is equally
   suited for more advanced cryptographic approaches.  What this
   specification adds, is a facility for Kerberos authentication,
   without resorting to the use of a KDC as a mere password oracle for
   PAP.  To make this possible, the Application Protocol (AP) exchange
   of Kerberos is facilitated over EAP.

   Since EAP is so often used to bootstrap online access, as is the case
   with PPP and 802.1x use cases, additional care is needed for
   procuring Kerberos tickets to use in the AP exchange.  To facilitate
   this, the EAP profile presented herein can also be used to pass
   Authentication Service (AS) and Ticket Granting Service (TGS)
   exchanges with a Kerberos-supportive backend.

   For users, the applications of EAP are integrated with a Single Sign-
   On (SSO) facility, making their online experience more seemless




Van Rein               Expires September 14, 2016               [Page 2]

Internet-Draft                EAP-Kerberos                    March 2016


   because no separate password entry is required, nor is it required to
   resort to fixed secrets installed on their systems.

   The following Security Claims [Section 7.2 of [RFC3748]] are made for
   EAP-Kerberos:

   Auth. mechanism:           Kerberos
   Ciphersuite negotiation:   Yes
   Mutual authentication:     Yes
   Integrity protection:      No (not for EAP header fields)
   Replay protection:         Yes
   Confidentiality:           No, not always and not completely
   Key derivation:            Yes
   Key strength:              Usually 128 or 256 bit
   Dictionary attack prot.:   No
   Fast reconnect:            Yes
   Crypt. binding:            Yes, as implied by Kerberos
   Session independence:      Yes
   Fragmentation:             Yes
   Channel binding:           No

2.  Inner and Outer Identities

   It is common for EAP to be encapsulated in a context that
   communicates an identity, independently of what the EAP does with it.
   This identity is sometimes referred to as the "outer" identity, to
   contrast it with an "inner" identity negotiated within the EAP
   transport.  As an example, when EAP is transported in RADIUS or
   Diameter, there is commonly a User-Name attribute at the same level
   as EAP; this would be the outer identity.

   Not all methods distinguish between inner and outer identities and
   under such methods the outer identity often holds a user name to be
   authenticated.  This is not strictly required in an EAP context; the
   only thing needed is a decision from the backend to Accept or Reject
   a peer; any data exchanged works towards that end result.

   Under EAP-Kerberos, the client PrincipalName and Realm may be
   considered the inner identity, and indeed is this the identity that
   is validated by the protocol flow.  It is vital to understand that
   the outer identity is in no way to be considered reliable as a user
   identity for the peer; this is because it falls outside the protected
   context of EAP-Kerberos.

   The outer identity serves a different goal, namely as a locator for
   the backend authorisation server.  To the peer, this is a backend
   that is supportive of its access, and to the authenticator this is a
   basis for locating and/or constraining the backend server as an



Van Rein               Expires September 14, 2016               [Page 3]

Internet-Draft                EAP-Kerberos                    March 2016


   authoritative source of information about the peer and its rights of
   access to the EAP-protected resource.

3.  Transporting Kerberos Frames over EAP

   The EAP-Kerberos protocol carries an ordered flow of Kerberos frames,
   communicated in round trips.  This facilitates a Kerberos query/
   response sequence initiated by the peer, and leading to eventual
   Succes or Failure to authenticate the peer.  This section details
   what Kerberos frames are, and how an EAP message flow implements
   them.

   Whenever a fatal error is detecting during the processing of EAP-
   Kerberos, this MUST lead to rejection of the authentication attempt,
   possibly after delivery of a final KRB-ERROR frame.  Any conflict
   with the specifications is considered a fatal error.

3.1.  EAP-Kerberos as a Flow of Kerberos Frames

   EAP-Kerberos implements a flow of Kerberos frames.  Each Kerberos
   frame is a single data structure, recognised by an [APPLICATION n]
   tag.  The exchange between the authenticating peer and backend
   authentication server consists of a request/response interaction: The
   peer sens a request and the backend sends a response (which may be an
   error message).

   The transmission channel of EAP-Kerberos is half-duplex, meaning that
   the peer and backend take turns sending messages.  Each sends one
   Kerberos frame and is then open for another.  In the case of the
   peer, receiving a Kerberos frame makes him free to send another, and
   in case of the backend, having receiving a Kerberos frame initiates
   its handling.

3.2.  Format of a Kerberos Frame

   A Kerberos frame is defined as a single DER-encoded data structure,
   so a single tag with length and a value that may hold more DER data.
   The outermost tag and length are of explicit use to EAP-Kerberos.

   The outermost tag MUST be an [APPLICATION n] tag.  The tag indicates
   what meaning the frame has in the context of the Kerberos application
   [usually according to [RFC4120]].  The tag may facilitate relaying
   decisions, especially in the backend authentication server.  Finally,
   the tag indicates a syntax that the entire Kerberos frame MUST adhere
   to.

   The outermost length is used in the collection of a Kerberos frame
   that MAY have gotten fragmented over multiple EAP frames.  The first



Van Rein               Expires September 14, 2016               [Page 4]

Internet-Draft                EAP-Kerberos                    March 2016


   EAP frame to transport a Kerberos frame holds the outermost tag and
   length and a failure to contain both within this first message MAY be
   treated as a fatal error.

   As a result of these definitions, Kerberos frames can be
   concatenated; the DER encoding clearly marks where one Kerberos frame
   ends and the next one starts.  This does not mean that such
   concatenation is permitted within an EAP frame; in fact, it is
   considered a fatal error if an EAP frame contains excess bytes after
   the end of a Kerberos frame.

3.3.  Encapsulation of Kerberos Frames in EAP

   A Kerberos frame is cut into one or more non-empty fragments that
   lead to EAP frames that fit in the MTU for EAP frames.  The EAP-
   Kerberos protocol consists of such individually encapsulated
   fragments, as well as acknowledgement packages.

   To enapsulate a Kerberos fragment, the standard EAP packet header
   [Section 4 of [RFC3748]] is prepended, consisting of the fragments's
   Code, Identifier and Length.  Note that it is possible to include a
   Kerberos fragment with a Success or Failure EAP frame that holds the
   Success or Failure code, not just for Request or Response codes.

   The Length field holds five more than the non-zero number of bytes of
   the contained Kerberos fragment, and it should be noted that any
   further bytes count as padding in the data link layer, so these
   should not be taken into account when reconstructing a Kerberos frame
   from fragments in EAP frames.  EAP packets with Length set to 1 hold
   no Kerberos data but are instead used to acknowledge the reception of
   traffic up to the given Identifer.

   The Type field is always set to the value TBD assigned by IANA as the
   Method Type for EAP-Kerberos.

   When a Kerberos frame falls apart into multiple fragments, then all
   these fragments are submitted individually, with an Identifier byte
   value that increments from the value of its first packet.  This is
   useful on the receiving end, where the portions must be recollected.
   When it transpires that EAP frames were not received in good order,
   they MUST be retransmitted.  Indications of such ill-received EAP
   frames are received through special acknowledgement EAP frames.  The
   Identifier starts from 0 for each new Kerberos frame, so the initial
   EAP frame for a Kerberos frame is easily recognised.

   When encapsulating a Kerberos fragment, the EAP frame always has a
   Length over 5.  There is an additional EAP frame used to acknowledge
   having received prior frames, and this is a frame with Length equal



Van Rein               Expires September 14, 2016               [Page 5]

Internet-Draft                EAP-Kerberos                    March 2016


   to 5.  It SHOULD only be sent on the last frame before an apparent
   gap in the frame sequence, and in addition it MUST be sent on the
   last frame that completes the reconstruction of a Kerberos frame.
   Acknowledgement packets replicate the Identifier tag from the last
   EAP frame that they received in good order.  TODO: Is this possible,
   or MUST it be a roundtrip to satisfy carriers such as RADIUS?

   Only when a complete Kerberos frame has been reconstructed on the
   receiving end, is it possible to send the next message in the
   opposite direction.  The backend authentication server can start to
   build a response after receiving a Kerberos frame, and the
   authenticating peer can choose if it wants to send another request in
   a Kerberos frame.

4.  Component Support for EAP-Kerberos

   The following subsections indicate what support is needed for EAP-
   Kerberos to be used.

4.1.  Peer Support for EAP-Kerberos

   In EAP terminology, the (authenticating) peer is the endpoint that
   wants to be authenticated by the Authenticator.  It must have
   explicit support for EAP-Kerberos.

   When the peer has no valid ticket granting ticket, or when it prefers
   to use another for EAP-Kerberos, then it should first get one using
   the AS exchange [Section 3.1 of [RFC4120]].

   When the peer has no valid service ticket, or when it prefers to use
   another one, for EAP-Kerberos, then it should get one (or multiple)
   using the TGS exchange [Section 3.3 of [RFC4120]].

   Finally, the peer will want to authenticate with the backend server.
   To do that, it uses the service ticket in a double AP exchange
   [Section 3.2 of [RFC4120]]:

   1.  The first AP request [Section 5.5.1 of [RFC4120]] sent from peer
       to backend includes no cksum, but supplies a randomly generated
       seq-number in its Authenticator.  It does not include a subkey.

   2.  The first AP response [Section 5.5.2 of [RFC4120]] sent from
       backend to peer contains a subkey and a seq-number field that is
       one more than the seq-number field in the first AP request.  The
       subkey is stored by the peer as its master key.

   3.  The second AP request sent from the peer to the backend includes
       a cksum computed over the EncAPRepPart of the first AP response,



Van Rein               Expires September 14, 2016               [Page 6]

Internet-Draft                EAP-Kerberos                    March 2016


       after it has been decrypted into a DER structure.  The seq-number
       field is one higher than the seq-number field in the first AP
       response.  The hash assures the peer's ability to decrypt, and
       thus ownership of the key; the seq-number may help to assure
       extra protection from replay.  The second AP request additionally
       holds a subkey that the backend should henceforth be used by the
       backend.  The second AP request is encrypted with the subkey
       found in the first AP response.

   4.  The second AP response sent from backend to peer includes no
       subkey but it does hold a seq-number which is one higher than the
       seq-number from the second AP request.  The second AP response is
       encrypted with the subkey found in the second AP request.

   This exchange establishes mutual authentication between the peer and
   backend.

   Peers SHOULD support at least the above variations of Kerberos frame
   flow, but they MAY attempt to do more; specifically, it may attempt
   to perform other AS, TGS and AP exchanges than what is strictly
   needed for authentication to commence.  All this must be done before
   the final authentication step is made.

4.2.  Authenticator Support for EAP-Kerberos

   In EAP terminology, the authenticator is the part of the
   infrastructure that wants to know if the authenticating peer can be
   granted access.  It often coincides with the Network Access Server in
   the customary EAP use case of granting network access.

   The authenticator SHOULD NOT modify EAP-Kerberos messages that it
   passes between peer and a backend authentication server.
   Specifically, it MUST NOT filter on [APPLICATION n] tags of Kerberos
   frames.

   In summary, there is nothing that needs to change to an authenticator
   to be able to pass EAP-Kerberos.

4.3.  Backend Support for EAP-Kerberos

   In EAP terminology, the backend (authentication server) is the
   endpoint for EAP that makes the decision to grant or deny access to
   the authenticating peer.  It is usually a server that runs an AAA
   protocol such as RADIUS or Diameter.

   To facilitate EAP-Kerberos, the backend reconstructs Kerberos frames
   from EAP frames, and either handles them locally or relays them as
   permitted by configured policy.



Van Rein               Expires September 14, 2016               [Page 7]

Internet-Draft                EAP-Kerberos                    March 2016


   It is RECOMMENDED for backends to facilitate AS and TGS requests
   [Section 5.4.1. of [RFC4120]] from the peer, and relay those to a
   KDC.  In both cases, the backend SHOULD perform KDC Discovery
   [Section 7.2.3 of [RFC4120]] to find the KDC, based on the realm
   field in the request.  It relays the Kerberos frame to this
   discovered KDC, and awaits a reply (or produces a timeout error to
   replace it).  The reply is relayed back to the peer as a Kerberos
   frame encapsulated in EAP frames.

   The backend MAY additionally relay AP requests [Section 5.5.1 or
   [RFC4120]] to servers when configured to do so; in this case the
   realm and sname fields of the contained ticket are helpful to locate
   the target for relaying.  The applications KRB-SAFE, KRB-PRIV and
   KRB-CRED have no indication of the protocol being used, so their
   relaying is less likely.  What this means is that the facility for
   relaying AP requests is rather limited, and only suitable for
   situations that require nothing but the AP requests themselves; it
   may be useful to exchange key materials in the backend
   infrastructure, such as end-to-end key material.

   The backend MUST accept AP requests directed to a service name of its
   own.  Such requests are processed under the following rules:

   o  Upon arrival of an AP request, the encrypted part is decrypted, by
      default with the encryption contained in the ticket.  When a
      subkey has been previously supplied to the peer in the current
      EAP-Kerberos session, then this replaces the default encryption
      key from the ticket.

   o  An AP request from the peer has a seq-number field, and the
      response MUST have a seq-number increased by one.

   o  When the peer has not been sent a subkey before, one is generated
      from a good random source, and sent in the AP response.  This is
      done only once per EAP-Kerberos session.

   o  Every AP request receives an AP response or a KRB-ERROR; this is
      even true if the AP request leads to the deciding one.  The AP
      response is encrypted with the key in the ticket by default; when
      a subkey has just been supplied by the AP request from the peer,
      then this is used instead.

   o  When timing in the AP request diverts too far from the clock time
      of the backend, then an error is sent instead of an AP response.
      It is common to permit a time window of about five minutes around
      the backend clock time.





Van Rein               Expires September 14, 2016               [Page 8]

Internet-Draft                EAP-Kerberos                    March 2016


   An AP request leads to the final decision of either Failure or
   Success when a subkey has been sent to the peer, when the peer just
   sent a subkey and cksum in the encrypted part of the AP request.  The
   decision is Failure, except when all the following requirements are
   met and the decision therefore becomes Success:

   o  The timing information diverts is close enough to the clock time
      of the backend.

   o  The seq-number is one more than the seq-number that was sent to
      the peer in a preceding AP response sent during this EAP-Kerberos
      session;

   o  The cksum is a correctly computed checksum over the DER-encoded
      bytes that hold the EncAPRepPart after decryption, taken from the
      foregoing AP response in the current EAP-Kerberos session.

   The backend MUST send exactly one Kerberos response to any Kerberos
   request that it receives.  If it receives a request encapsulated in
   EAP that it does not handle, then it MUST reply with a KRB-ERROR
   message [Section 5.9.1 of [RFC4120]] with a suitable error code
   [Section 7.5.1 of [RFC4120]], and/or trigger a fatal error.

5.  Established Master Key

   When an EAP-Kerberos session ends in Success, then both sides have
   provided a subkey to the other side, to be used for future
   communication towards them.  Upon success, these keys MAY be used to
   initiate any further keying requirements between the peer and the
   infrastructure setup by the backend.

   We do not prescribe the manner in which this is done, or how the
   master key is used to construct session keys, but leave it to the
   general remark that session keys should be derived in a manner that
   does not permit derivation of the master key or other session keys
   derived from it.

6.  Efficiency Considerations

   Among the uses of EAP are applications where no IP address has been
   obtained by the peer, such as gaining network access over PPP or
   Ethernet protocols with 802.1x protection.  In such networks, it may
   be required to bootstrap Kerberos tickets that would be needed for
   EAP-Kerberos.  This is why AS and TGS exchanges may be passed over
   EAP, and why the backend server may support such exchanges by
   relaying such traffic to a KDC.





Van Rein               Expires September 14, 2016               [Page 9]

Internet-Draft                EAP-Kerberos                    March 2016


   Once access to a network has been granted, there may be an additional
   need to encrypt traffic, and facilitate authentication.  For such
   exchanges, there may be a use for additional Kerberos exchanges.
   This is why this specification leaves room for such additional
   exchanges, without enforcing them.

7.  Privacy Considerations

   The EAP-Kerberos exchange reveals some information that may be
   considered private.  This may be a privacy concern in infrastructures
   that pass the EAP-Kerberos data through third party network
   components.  It is possible facilitate privacy for any intermediate
   EAP relays by sending EAP-Kerberos within EAP tunneling mechanisms,
   such as EAP-TTLS [RFC5281] or EAP-FAST [RFC4851].

8.  Security Considerations

   Tunneling is not required for reasons of security; Kerberos frames
   are designed to travel over untrusted networks.

   When EAP-Kerberos travels in the company of attributes descriptive of
   the peer, it is important to understand that nothing that EAP-
   Kerberos will do can assign any validity to these attributes.  The
   "innert" identity as mentioned in Kerberos packets is what is
   validated.  Any "outer" identity as mentioned in such companion
   attributes is more inclined towards routing than to identification.

   The peer and its KDC establish end-to-end trust on the basis of their
   pre-shared secret.  This is subsequently used to infer trust on
   derived keys and tickets.  For the intermediaries (namely, the
   authenticator and even the backend authentication server) the secret
   is not known, and so they may need extra bases for trust in the
   established relationship.  Specifically, where the lookup of a KDC
   does not require DNSSEC to secure the client, it will often be
   instrumental for such intermediate pieces of the infrastructure to
   establish trust in the authenticity of the KDC for a particular realm
   or domain name.  Note however that the eventual use of the AP
   exchange between the peer and its backend should imply an alternative
   trust basis between these two players, through either a shared KDC or
   two that have a secure realm-crossover relationship.  This leaves the
   authenticator as the main party to protect itself; note that this
   party can be especially sensitive when it takes action based on
   companion attributes that travel back with an EAP-Kerberos Success.








Van Rein               Expires September 14, 2016              [Page 10]

Internet-Draft                EAP-Kerberos                    March 2016


9.  IANA Considerations

   This specification requests the registration of a Method Type in the
   Extensible Authentication Protocol (EAP) Registry, from the range
   granted through the Designated Expert with Specification Required
   procedure.  IANA has assigned TBD to the EAP method specified herein.

10.  References

10.1.  Normative References

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, Ed., "Extensible Authentication Protocol
              (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
              <http://www.rfc-editor.org/info/rfc3748>.

   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
              Kerberos Network Authentication Service (V5)", RFC 4120,
              DOI 10.17487/RFC4120, July 2005,
              <http://www.rfc-editor.org/info/rfc4120>.

10.2.  Informative References

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, DOI 10.17487/RFC2865, June 2000,
              <http://www.rfc-editor.org/info/rfc2865>.

   [RFC4851]  Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
              Flexible Authentication via Secure Tunneling Extensible
              Authentication Protocol Method (EAP-FAST)", RFC 4851,
              DOI 10.17487/RFC4851, May 2007,
              <http://www.rfc-editor.org/info/rfc4851>.

   [RFC5281]  Funk, P. and S. Blake-Wilson, "Extensible Authentication
              Protocol Tunneled Transport Layer Security Authenticated
              Protocol Version 0 (EAP-TTLSv0)", RFC 5281,
              DOI 10.17487/RFC5281, August 2008,
              <http://www.rfc-editor.org/info/rfc5281>.

   [RFC6733]  Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
              Ed., "Diameter Base Protocol", RFC 6733,
              DOI 10.17487/RFC6733, October 2012,
              <http://www.rfc-editor.org/info/rfc6733>.







Van Rein               Expires September 14, 2016              [Page 11]

Internet-Draft                EAP-Kerberos                    March 2016


Author's Address

   Rick van Rein
   ARPA2.net
   Haarlebrink 5
   Enschede, Overijssel  7544 WP
   The Netherlands

   Email: rick@openfortress.nl










































Van Rein               Expires September 14, 2016              [Page 12]