(To tell truth, I _don't_ enjoy arguing semantics!)
Hallam-Baker, Phillip <pbaker(_at_)verisign(_dot_)com> wrote:
The Internet Security glossary is not a definitive work, it is an
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.
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.
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.
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.
"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".)
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.
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".)
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.)
(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.)
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.)
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%.
A MARID record answers the question 'does the mail come from the
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:]
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.
Did you intend to answer "Yes" or "No"?
--
John Leslie <john(_at_)jlc(_dot_)net>