Subject: Proposed charter and milestone revision for CAT-WG

From: "Linn, John" <[email-masked]>
Date: Wed, 12 May 1999 10:30:05 -0400

CAT fanciers:

I've received a request from the IESG to propose a revision and update to
the CAT-WG's charter and milestone list, which has become outdated and needs
to reflect current activities.  Here's a draft, based on activity observed
within recent months; it also proposes completion dates (which we should
regard as commitments to the IESG, so please propose adjustments if
necessary). Let's discuss this on the list as needed between now and next
Tuesday (18 May), so that it can be submitted for IESG consideration soon
thereafter. Thanks in advance for your review and consideration.

--jl

Description of Working Group:

The goal of the Common Authentication Technology (CAT) Working Group is to
provide distributed security services (including authentication, integrity,
and confidentiality) to a variety of protocol callers in a manner which
insulates those callers from the specifics of underlying security
mechanisms.

By separating security implementation tasks from the tasks of integrating
security data elements into caller protocols, those tasks can be partitioned
and performed separately by implementors with different areas of expertise.
This provides leverage for the IETF community's security-oriented resources,
and allows protocol implementors to focus on the functions their protocols
are designed to provide rather than on characteristics of security
mechanisms. CAT seeks to encourage uniformity and modularity in security
approaches, supporting the use of common techniques and accommodating
evolution of underlying technologies.

In support of these goals, the working group pursues several interrelated
tasks. We have defined a common service interface (GSS-API) allowing callers
to invoke security services in association-oriented environments, with an
associated token format identifying the security mechanism being employed.
Existing documents provide C language bindings for GSS-API; currently
ongoing work is defining bindings for Java.  Authorization interfaces are
currently being considered as a related area for follow-on work.  The CAT
Working Group also defines supporting mechanisms to provide security
services; current activity includes specification of "low-infrastructure"
mechanisms to support ease of deployment and use.  

Goals and Milestones:

Done: Submit GSS-V2, Update 1 base specification and C bindings to IESG for
consideration as new Proposed Standards to obsolete RFCs 1509 and 2078.

Jul 99: Agree on plan re progressing authorization interfaces. 

Jul 99: Agree on plan re progressing low-infrastructure mechanism
definitions. 

Aug 99: Submit GSS-V2 Java bindings specification to IESG for consideration
as Proposed Standard.

Aug 99: Submit Kerberos Public-Key Initial Authentication (PKINIT) document
to IESG for consideration as Proposed Standard.

Aug 99: Submit revision to Kerberos mechanism to IESG as new Proposed
Standard to succeed RFC-1510.

Sep 99: Submit GSS-V2 Java service provider interface document to IESG for
consideration as Proposed Standard. 

==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Frank Siebenlist <[email-masked]>
Date: Thu, 13 May 1999 10:10:34 -0700

John,

The statement: "Authorization interfaces are currently being considered as a related area for follow-on work" doesn't sound very convincing...

Understand that authorization is being dealt with in a number of other working groups, but if we believe that authorization services should be an integral part of the CAT working group's charter, you may want to add them to the goal statement:

"The goal of the Common Authentication Technology (CAT) Working Group is to
provide distributed security services (including authentication, integrity, confidentiality, and authorization) to a variety of protocol callers in a manner 
                 ^^^^^^^^^^^^^^^^^
which insulates those callers from the specifics of underlying security mechanisms."

If we don't want to do that, we should ask the IESG for guidance and find a "real" home for authorization services.

-Frank.

-- 
Frank Siebenlist              DASCOM, Inc. 
Chief Architect               3004 Mission Street
Email: [email-masked]       Santa Cruz, CA 95060, USA
Phone: +1 831/460-3600        Fax: +1 831/460-0255
==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]