Subject: RE: terminology: authentication / authorization

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 9 Jul 2004 09:42:01 -0700

The Internet Security glossary is not a definitive work, it is an
attempt to describe definitions that already existed in the field.

The real definition of the terms authentication and authorization
is Butler Lampson's work in the 1970s.

The problem with pulling terms from the glossary is that there are
a bunch of assumptions built into the definitions that have to be
understood. It is even worse because the typography does not allow
terms of art to be distinguished. 

The computer security nomenclature was developed for non-networked
machines. Granting the right to perform an action is synonymous
with the ability to perform it.

Take a look at the definition itself and this becomes clear:

     An "authorization" is a right or a permission that is
     granted to A SYSTEM entity to access A SYSTEM resource. 

An authorization is NOT a right that is granted to an entity 
on one system to access a resource on another system which is
what people are trying to make it.

According to the glossary what we have is a credential:

   $ credential(s)
      (I) Data that is transferred or presented to establish either a
      claimed identity or the authorizations of a system entity. (See:
      authentication information, capability, ticket.)

Most authentication credentials conflate authorization information
in some degree. A username and password record conflates permission
to log on to the machine, an SSL certificate conflates permission to
turn on the padlock icon. This does not mean that it is useful to
call authentication and authorization the same thing.

A MARID record answers the question 'does the mail come from the
purported domain', that makes it an authentication credential.

The motives of the writer are completely irrelevant, what is 
important here is the interpretation of the reader, that is the
only thing that gives the record meaning.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of John Leslie
> Sent: Friday, July 09, 2004 10:30 AM
> To: Dave Crocker
> Cc: Meng Weng Wong; [email-masked]
> Subject: Re: terminology: authentication / authorization
> 
> 
> 
> Dave Crocker <[email-masked]> wrote:
> > 
> > This groups needs to stop re-defining well-established security
> > terminology, especially when the primary effect of those 
> redefinitions
> > is to make everything less consistent and precise, not more.
> 
>    I've been trying to hunt down useful definitions in common use;
> I can supply links if anyone's a glutton for punishment.
> 
>    The only source I feel able to recommend for our use is RFC 2828:
> "Internet Security Glossary", May 2000. It lists several categories
> of entries:
> 
> - "I" identifies a RECOMMENDED Internet definition.
> - "N" identifies a RECOMMENDED non-Internet definition.
> - "O" identifies a definition that is not recommended as the 
> first choice
>       for Internet documents but is something that authors of Internet
>       documents need to know.
> - "D" identifies a term or definition that SHOULD NOT be used 
> in Internet
>       documents.
> - "C" identifies commentary or additional usage guidance.
> 
>    From RFC 2828, I extract:
> 
> ] accreditation
> ]   (I) An administrative declaration by a designated authority that
> ]       an information system is approved to operate in a particular
> ]       security configuration with a prescribed set of safeguards.
> ]       [FP102] (See: certification.)
> ]   (C) An accreditation is usually based on a technical certification
> ]       of the system's security mechanisms. The terms "certification"
> ]       and "accreditation" are used more in the U.S. Department of
> ]       Defense and other government agencies than in commercial
> ]       organizations. However, the concepts apply any place where
> ]       managers are required to deal with and accept responsibility
> ]       for security risks. The American Bar Association is developing
> ]       accreditation criteria for CAs.
> ] 
> ] authentication
> ]   (I) The process of verifying an identity claimed by or for a
> ]       system entity. (See: authenticate, authentication exchange,
> ]       authentication information, credential, data origin
> ]       authentication, peer entity authentication.)
> ]   (C) An authentication process consists of two steps:
> ]       1. Identification step: Presenting an identifier to the
> ]          security system. (Identifiers should be assigned carefully,
> ]          because authenticated identities are the basis for other
> ]          security services, such as access control service.)
> ]       2. Verification step: Presenting or generating authentication
> ]          information that corroborates the binding between 
> the entity
> ]          and the identifier. (See: verification.)
> ]   (C) See: ("relationship between data integrity service and
> ]       authentication services" under) data integrity service.
> ] 
> ] authorization
> ]   (I) (1.) An "authorization" is a right or a permission that is
> ]            granted to a system entity to access a system resource. 
> ] 	(2.) An "authorization process" is a procedure for granting
> ]            such rights.
> ] 	(3.) To "authorize" means to grant such a right or permission.
> ]       (See: privilege.)
> 
>    Since only the (I) items are "recommended", is there any reason we
> can't live with:
> 
> " Accreditation is an administrative declaration by a 
> designated authority
> "   that an information system is approved to operate in a particular 
> "   security configuration with a prescribed set of safeguards. 
> 
> " Authentication is the process of verifying an identity claimed by or
> "   for a system entity.
> 
> " Authorization is a right or a permission that is granted to a system
> "   entity to access a system resource.
> 
> --
> John Leslie <[email-masked]>
>

---

From: John Leslie <[email-masked]>
Date: Fri, 9 Jul 2004 15:21:18 -0400

(To tell truth, I _don't_ enjoy arguing semantics!)

> attempt to describe definitions that already existed in the field.

   Quite true; but it does recommend usage, which I'd like to believe
we could agree to follow.

> with the ability to perform it.

   May I remind everyone that RFC2828 is dated May, 2000, and discusses
terms in use to describe "Internet" ideas. Whatever baggage the
definitions may carry from pre-network days, I'm sure the issue was
carefully considered in relation to thirty years of internetworking
experience.

>      granted to A SYSTEM entity to access A SYSTEM resource. 

   "System" is a handwaving term, IMHO.

   (BTW, I agree with Phil that this definition may not fit perfectly.
But we must consider it, since the IESG carefully chose to name this
group "MTA Authorization Records in DNS".)

> what people are trying to make it.

   I agree completely.

   I find "permission" to be more useful than "right" in our context.

   Also, IMHO "system" must be interpreted broadly to consider the
cloud of MTAs that constitute the email system on today's Internet.

   Thus, I must believe that IESG was thinking in terms of the
granting of "permission" to access the TCP connectivity of the
Internet in order to transfer email to other MTAs in the overall
email system.

   (I'm not sure how helpful that is: personally, I want authorization
to mean is that the management of the domain doing the authorizing
agrees to accept responsibility for actions it authorizes. But I've
come to accept that we can't squeeze that into the meaning of
"authorization".)

>       authentication information, capability, ticket.)

   (That is accurately quoting RFC2828. I'll be happy to agree with it,
if anyone thinks that will help.)

   We do, however, need to be careful _what_ we claim is a credential.
(This question hasn't arisen much; so I'm not anxious to argue it.)

> in some degree.

   If you insist on "conflate", I'll have to disagree. To the extent
you mean "combine", though, I'm willing to agree. (I've long since
given up hope anyone will believe I don't _enjoy_ semantic arguments.)

> A username and password record conflates permission to log on to
> the machine, an SSL certificate conflates permission to turn on the
> padlock icon.

   Username/password is pure authentication, by whatever process it
may be accomplished. The authentication module is virtually always
unaware of what permissions may follow from the authentication.
Indeed permissions are checked by entirely different processes at
entirely different times.

   (SSL doesn't deserve discussion right now, IMHO.)

> This does not mean that it is useful to call authentication and
> authorization the same thing.

   I agree 100%.

> purported domain', that makes it an authentication credential.

   You're losing me, Phil. What MARID record are you talking about?

   In CSV we'd be talking about the SRV record, which is quite clearly
"transferred" to "establish" the "authorization" to access the network
as an MTA client. The "authentication" comes along for the ride, based
on DNS servers automatically returning Address RRs as additional info.
The CSV record makes no statement whatsoever about author, sender,
or forwarder, merely about the assertion of the EHLO string.

   In Sender-ID, the spec is clear that the TXT record contains a
statement of "policy"; and that its active elements are to be
interpreted as a "function" returning "pass" or not. "Pass" means:
] 
] 6.1 pass
]   A "pass" result from the check means that the domain has authorized
]   the sending of the message in question. An SMTP server receiving this
]   result SHOULD accept the message.

   I really don't see how that is equivalent to "does the mail come from
the purported domain?"

   Further, I don't see how it's "transferred" to "establish" a "claimed
identity", which is the only way I could see it as an "authentication
credential".

> The motives of the writer are completely irrelevant,

   I sincerely hope we don't need to discuss those.

> what is important here is the interpretation of the reader, that is
> the only thing that gives the record meaning.

   Hopefully, specs will define interpretation well enough that we don't
need to guess at how each reader will interpret it...

====

   Oh, one last thing:
> [John Leslie wrote:]
>> " Accreditation is an administrative declaration by a designated authority

   Did you intend to answer "Yes" or "No"?

---

From: Meng Weng Wong <[email-masked]>
Date: Fri, 9 Jul 2004 18:13:23 -0400

On Fri, Jul 09, 2004 at 03:21:18PM -0400, John Leslie wrote:
| > Most authentication credentials conflate authorization information
| > in some degree.
| 
|    If you insist on "conflate", I'll have to disagree. To the extent
| you mean "combine", though, I'm willing to agree. (I've long since
| given up hope anyone will believe I don't _enjoy_ semantic arguments.)

I think we need to agree on terminology here.

Is there an RFC that defines "conflate" versus "combine"?

Just kidding.  :)

---

From: Dave Crocker <[email-masked]>
Date: Sat, 10 Jul 2004 17:07:14 +0700

JL>    May I remind everyone that RFC2828 is dated May, 2000, and discusses
JL> terms in use to describe "Internet" ideas. Whatever baggage the
JL> definitions may carry from pre-network days, I'm sure the issue was
JL> carefully considered in relation to thirty years of internetworking
JL> experience.

  For reference, folks, the current IETF Security ADs suggest using
  this document.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>