Subject: [Ietf-krb-wg] EPAK extension proposal

From: "Phillip Hellewell" <[email-masked]>
Date: Wed, 19 Nov 2008 18:05:20 -0700

Hello, my name is Phillip Hellewell.  I attended Brigham Young
University's Computer Science graduate program where I worked in the
Internet Security Research Lab.  As part of my research I designed and
implemented a Kerberos extension called EPAK with my advisor Dr. Kent
Seamons in 2007.

   EPAK (Extensible Pre-Authentication in Kerberos) was presented at ACSAC
2007. The ACSAC paper can be obtained in PDF format here:
http://www.acsac.org/2007/abstracts/30.html.

P. L. Hellewell, T. W. van der Horst, and K. E. Seamons. Extensible
Pre-Authentication in Kerberos. 23rd Annual Computer Security Applications
Conference (ACSAC), Miami, FL, December 2007.

   Below is a brief introduction to EPAK.  Work is underway for creating an
Internet draft, and I would like to see this as a working group item; any
comments about EPAK and help in the standardization process will be greatly
appreciated.

   Thanks,
   Phillip Hellewell

Introduction to EPAK

   Unlike most Kerberos extensions, EPAK does not add support for a specific
type of authentication.  Instead it is a framework that enables many
authentication schemes to be loosely coupled with Kerberos, without further
modification to Kerberos.  Traditionally, new extensions work by modifying
the first phase of Kerberos to support a specific type of pre-authentication
data in the AS request.  EPAK also modifies phase 1 of Kerberos (to support
the KRB5-PADATA-EPAK padata type), but the (pre) authentication happens
previously in a separate step (described as phase 0) that does not involve
the KDC at all.  This pre-authentication phase works uniquely for each type
of authentication, but like other Kerberos phases it ultimately results in a
ticket and session key being stored into the client's credential cache.  The
ticket obtained in phase 0 (pre-authentication) is sent to the AS/KDC in
phase 1 inside the padata field of type KRB5-PADATA-EPAK.

   In other words, EPAK cleanly separates pre-authentication and AS
authentication so that a variety of authentication systems can be loosely
coupled with Kerberos.  Once EPAK support is in place, new authentication
systems can be enabled without modifying Kerberos.  EPAK is especially
useful for integrating authentication systems that are complex, slow, or
don't fit into the regular one-round phase 1 of Kerberos.  It is also useful
as a mechanism to extend Kerberos functionality when access to the source
code is not available (e.g., Microsoft implementations).

   To demonstrate the utility of the EPAK framework, two authentication
methods for open systems have been implemented as Kerberos extensions using
EPAK.  They are trust negotiation and SAW (email-based authentication).
These extensions illustrate the flexibility EPAK brings to Kerberos while
maintaining backwards compatibility.  You can learn more about EPAK, trust
negotiation, and SAW at the ISRL website: http://isrl.cs.byu.edu/.

   Source code for EPAK (a patch to Heimdal 0.8.1) can be obtained here:
http://isrl.cs.byu.edu/software.php

   Some preliminary work has begun on EPAK standardization.  With help from
Love Astrand and Tom Yu, we have obtained an official PADATA number:
KRB5-PADATA-EPAK (130).  (We are also trying to reserve another number,
e.g., 131, since EPAK actually has two types of messages:
KRB5-PADATA-EPAK-AS-REQ and KRB5-PADATA-EPAK-AS-REP.)
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 19 Nov 2008 17:38:31 -0800

Phillip Hellewell wrote:
> >    Some preliminary work has begun on EPAK standardization.  With help 
> from Love Astrand and Tom Yu, we have obtained an official PADATA 
> number: KRB5-PADATA-EPAK (130).  (We are also trying to reserve another 
> number, e.g., 131, since EPAK actually has two types of messages: 

131 and 132 are used by the OTP draft.

I don't think it's necessary for req/resp PADATA type pairs to be 
sequential.

-- 
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg