RFC 1511

Common Authentication Technology Overview

πŸ“… published September 1993, from ietf

Common Authentication Technology Overview πŸ¦‹

okay bestie, let's talk about RFC 1511 πŸ’… It's the Common Authentication Technology Overview πŸŽ€, written by John Linn (J. Linn) at Geer Zolot Associates, dated September 1993, from the Network Working Group 🌸. It's an info memo for the Internet community, not a standard. It's not a specification, so there's no spec-level stuff to implement from it 🫢 The original title block also has no Obsoletes or Updates entries, so this doc doesn't replace or change any other RFC πŸ”₯


Status of this Memo ✨

This memo gives information to the Internet community and does not specify an Internet standard. Distribution of this memo is unlimited πŸ“£

Overview 🌈

the IETF's Common Authentication Technology (CAT) working group has been on a whole journey with a bunch of connected work 🧚 They're doing both service interfaces AND protocols. The big goal is to separate the security implementation tasks from putting security data elements into caller protocols. That way, different experts can handle each part on their own πŸ’œ It's giving divide and conquer, and it's lowkey genius because one security implementation can plug into and be used by many caller protocols, so the IETF security crew gets major leverage πŸ”₯ Protocol implementers also get to focus on what their protocols are actually for, instead of the specifics of each security mechanism, because there's an abstract service that multiple mechanisms can realize ✨

The CAT WG agreed on a common service interface, the Generic Security Service Application Program Interface (GSS-API), which lets callers invoke security functions πŸ’– They also agreed on a common security token format. It includes a way to identify the mechanism type that the security data elements should be interpreted with, which is so iconic πŸ‘‘ The GSS-API is a mechanism-independent model for security integration. It gives peer entity authentication to a bunch of different protocol callers and keeps those callers away from the messy details of the underlying mechanisms 🫢 With certain underlying mechanisms, it can also do per-message protection: data origin authentication, data integrity, and data confidentiality πŸ” All of this lives in a pair of RFCs: RFC-1508 (GSS-API) and RFC-1509 (concrete bindings for the GSS-API in the C language) πŸŽ€


Meanwhile, the CAT WG was also working on agreements about the underlying security technologies and their protocols that implement the GSS-API model πŸ’… Two candidate mechanisms are available right now as Internet specifications, and more are expected to show up later 🌸 RFC-1510 is a standards-track specification. It documents Kerberos Version 5, a secret-key cryptography technology contributed by the Massachusetts Institute of Technology πŸ”‘ RFC-1507 is an experimental specification. It documents the Distributed Authentication Services technology, which is based on X.509 public-key technology and was contributed by Digital Equipment Corporation πŸ“

References πŸ“š

  • [1] Kaufman, C., "Distributed Authentication Security Service", RFC 1507, Digital Equipment Corporation, September 1993.
  • [2] Linn, J., "Generic Security Service Application Program Interface", RFC 1508, Geer Zolot Associates, September 1993.
  • [3] Wray, J., "Generic Security Service API : C-bindings", RFC 1509, Digital Equipment Corporation, September 1993.
  • [4] Kohl, J., and C. Neuman, "The Kerberos Network Authentication Service (V5)", Digital Equipment Corporation, USC/Information Sciences Institute, September 1993.

Security Considerations πŸ”πŸ˜­

this section is serious, so pay attention πŸ™ˆ The security issues are discussed throughout the references listed above. Go read those! The security story lives there, and skipping it is a big no πŸ’€

Author's Address 🧚

John Linn
Geer Zolot Associates
One Main St.
Cambridge, MA  02142  USA

Phone: +1 617.374.3700
Email: Linn@gza.com
πŸ“¦ where this page comes from