Re: CAT WG Review Last-Call: draft-myers-auth-sasl-04.txt

[John Gardiner Myers <[e-mail]>]

John Linn <[e-mail]> writes:
> (1) The section proposes that IANA act as a comment clearinghouse,
> [...].  I'm not aware of precedent for IANA assuming
> this role with other registered objects: is there precedent for IANA
> taking on this responsibility, and/or has it been accepted by the IANA
> for this case?

This text was lifted from draft-ietf-822ext-mime-reg-04.txt, which I
believe is currently in IETF-wide Last Call.

> (2) The section suggests that authors of SASL mechanisms are
> "encouraged to seek community review and comment whenever that is
> feasible", by publishing as Internet-Drafts and optionally as
> Informational RFCs.  Nowhere in the section is the prospect of
> specifying SASL mechanisms through the IETF standards track mentioned.

I personally don't see the need to belabor the obvious, though I'm
certainly open to suggestios for clarifying wording.  I don't see the
need for the namespace complexity of
draft-ietf-822ext-mime-reg-04.txt.  There are going to be far fewer
SASL mechanisms than media types.

The situation is akin to assigning well known ports to protocols.
There needs to be a registry mapping names (ports) to mechanisms
(protocols).  The need to register the name/port is independent of the
need/desire to standardize the protocol.  We encourage, but do not
require the specifics of the protocol to be disclosed.  If, after
publishing an internet-draft as suggested by the registration
document, there is community interest, then the rest of the IETF
standards track process can continue.

> Given the fact that the SASL document defines three mechanisms
> (including GSS-API which, in turn, enables access to a variety of
> underlying security technologies), I'd expect that the need to define
> additional SASL-level mechanisms should be fairly rare and that, if
> such additional mechanisms were required for IETF purposes, their
> definitions would appropriately target the same standards-track status
> (and attendant community review) that SASL itself is targeting.

There is currently a mechanism named CHAP in IETF-wide Last Call.
There is also an unpublished anonymous-diffie-hellman mechanism that
has been developed by an SMTP server vendor.  (I am currently trying
to get the author of same to publish the spec as an I-D).

Frankly, I have no idea if the creation/registration of new SASL
mechanisms will be frequent or rare.  I suppose a large part of it
will depend on whether or not GSSAPI is accepted.

> Re section 5.2, 2nd paragraph, should the references here to "content
> type" instead say "SASL mechanism"?

Yes, fixed.

> Re section 6, I think it would be useful, in a cross-mechanism fashion
> or in conjunction with each mechanism's definition, to state what
> behavior should occur if the proferred authorization identity is not
> accepted by the server. 

Each mechanism states that the server must "verify" such-and-such.
The authorization of the identity in the credentials to authenticate
as the proferred authorization identity is but one thing each
mechanism requires be verified.

It is a rather fundamental concept that if any verification fails, the
exchange fails and the server indicates this through the method
defined in the protocol's profile.  Perhaps I should state this in
section 3?

> Re section 6.1, 2nd paragraph, 2nd sentence: are the Kerberos ticket
> and authenticator included contiguously, in that order, and is any
> other framing included within the message?

They are included contiguously, as krb_mk_req() in the MIT API
generates them.  This is fairly standard in Kerberos v4-based schemes.

> Re sec. 6.2.1, 3rd paragraph, and sec. 6.2.2, 2nd paragraph: both of these
> paragraphs contain references to "protection mechanisms"; I believe that
> they should be updated to "security layers" to match the term as used in
> Sec. 6.2.3.

fixed

> Sec. 6.3, 4th para, typo: "musth".

Was fixed based on someone else's comment.

-- 
_.John Gardiner MyersInternet: [e-mail]
LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up