Subject: comments on draft-ietf-cat-kerberos-set-passwd-02.txt

From: [email-masked] (Johan Danielsson)
Date: 03 Mar 2000 14:21:07 +0100

>   KRB-PRIV message (see [3]) This KRB-PRIV message must be generated
>   using the subkey from the authenticator in the AP-REQ data.
>
>   The user-data component of the message consists of the following
>   ASN.1 structure encoded as an OCTET STRING:

I feel very strongly that ASN.1 shouldn't be used for new protocols
defined by the IETF. Especially so, since this defines a new construct
(CHOICE) that is not part of RFC1510.

Btw, what does `encoded as an OCTET STRING' mean?

>   In the cleartext password case, if the old password is sent in the
>   request, the request is defined to be a change password request.

Why do you want the old password?

>      result string - from [4]:
>         This field is a UTF-8 encoded string which should be displayed
>         to the user by the client.

Why suddenly UTF-8? All strings in RFC1510 are of type GeneralString.

/Johan
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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: Jonathan Trostle <[email-masked]>
Date: Tue, 07 Mar 2000 18:15:50 -0800

>(CHOICE) that is not part of RFC1510.

Other people feel strongly that ASN.1 is a good choice since it's standard and there are many commercial compilers for it now.

>Btw, what does `encoded as an OCTET STRING' mean?

That's a mistake that I will fix. Thanks for catching it.
>Why do you want the old password?

The old password can be used for additional password policy checking - e.g., to make sure the new and old passwords are sufficiently different. 

>Why suddenly UTF-8? All strings in RFC1510 are of type GeneralString.

It's a carryover from change password version 1, if I recall correctly.
Jonathan

---

From: Ken Hornstein <[email-masked]>
Date: Wed, 08 Mar 2000 00:56:10 -0500

>Other people feel strongly that ASN.1 is a good choice since it's standard
>and there are many commercial compilers for it now.

Didn't Ted T'so post a long message about the use of ASN.1 for Kerberos
that ended with the line, "Friends don't let friends use ASN.1"? :-)

I would have to agree with Johan on this one.  I don't know if there
was ever a formal IETF statement on the use of ASN.1 for new protocols,
but I always thought it was "discouraged".

--Ken

---

From: [email-masked] (Johan Danielsson)
Date: 08 Mar 2000 21:18:40 +0100

Jonathan Trostle <[email-masked]> writes:

> Other people feel strongly that ASN.1 is a good choice since it's
> standard and there are many commercial compilers for it now.

It's a horribly complicated standard that also isn't freely available.
There are various crash-course documents describing small subsets of
it, but I don't think that it's a good idea to build public standards
on them.  The fact that someone is selling compilers is only a proof
that there are consumers, not that it's a good idea.

I'd rather see the use of something like XDR that has a wide
acceptance (you'll find a compiler for it on the nearest unix
machine), and is trivial to implement (and it still has all the
features we want).

I personally think that ASN.1 is evil.

> It's a carryover from change password version 1, if I recall correctly.

You're right, I must have completely missed that. Anyhow I'm not sure
it's a good idea to start using UTF-8 here, if the rest of the
Kerberos standard is using 10646 (I believe this is the implication of
the use of GeneralString, right?).

/Johan

---

From: Tom Yu <[email-masked]>
Date: 08 Mar 2000 15:26:54 -0500

>>>>> "kenh" == Ken Hornstein <[email-masked]> writes:

>>> I feel very strongly that ASN.1 shouldn't be used for new
>>> protocols defined by the IETF. Especially so, since this defines a
>>> new construct (CHOICE) that is not part of RFC1510.
>> 

Commercial compilers are often not a viable option for low-budget
projects and open-source code.

kenh> Didn't Ted T'so post a long message about the use of ASN.1 for
kenh> Kerberos that ended with the line, "Friends don't let friends
kenh> use ASN.1"? :-)

I seem to recall that...

kenh> I would have to agree with Johan on this one.  I don't know if
kenh> there was ever a formal IETF statement on the use of ASN.1 for
kenh> new protocols, but I always thought it was "discouraged".

Perhaps a working group should be formed to discuss the lack of an
IETF presentation layer... I'm only partially joking.

I have been contemplating the wisdom of using ASN.1 or any other of
various encodings that has the function of a "presentation layer".
There seems to have a fair amount of near-religious fervor against
ASN.1, and some not-quite-as-fervent support for ASN.1.  There are a
number of valid reasons both for and against the use of ASN.1 in IETF
protocols.  Most IETF protocols do not need the complexity that ASN.1
comes with, and can be addressed by XDR, line-oriented ASCII, XML
(yuck), etc.  One could argue that Kerberos and related protocols
aren't really deserving of the capabilities of ASN.1, but it is kind
of a toss-up in my opinion.

The main issues that I see are that the primary standards documents
relating to ASN.1 aren't widely available, and there is no extensive
guids on how to avoid certain common pitfalls associated with using
ASN.1.  The latter point I intend to address by writing an
Informational or BCP RFC about it.  The former isn't likely to get
fixed until we can convince the ITU-T or the ISO (less likely) to
release certain documents that IETF standards depend on for free to
the IETF community.

---Tom

---

From: Mike Eisler <[email-masked]>
Date: Wed, 8 Mar 2000 12:49:16 -0800 (PST)

> machine), and is trivial to implement (and it still has all the

Might as well go the full distance and use ONC RPC too. The MIT krb5 1.0
wad includes a complete RPC-based protocol to allow administrators to set
passwords, and more, and lets users change their password as well.

	-mre

---

From: [email-masked] (Johan Danielsson)
Date: 08 Mar 2000 22:20:32 +0100

Mike Eisler <[email-masked]> writes:

> The MIT krb5 1.0 wad includes a complete RPC-based protocol to allow
> administrators to set passwords, and more, and lets users change
> their password as well.

Yes, but it's complex and at least somewhat undocumented. These drafts
are attempts at simpler interfaces.

/Johan

---

From: Tom Yu <[email-masked]>
Date: 08 Mar 2000 16:37:05 -0500

>>>>> "joda" == Johan Danielsson <[email-masked]> writes:

joda> It's a horribly complicated standard that also isn't freely
joda> available.  There are various crash-course documents describing
joda> small subsets of it, but I don't think that it's a good idea to
joda> build public standards on them.

I will agree that the crash-course documents are no substitute for
reading the actual spec, if you can find it or afford it.  I don't
think anyone should be allowed to use ASN.1 in an IETF protocol unless
they've read and *understood* the actual spec, as opposed to random
crash-course documents that may be misleading in ways.

joda> I'd rather see the use of something like XDR that has a wide
joda> acceptance (you'll find a compiler for it on the nearest unix
joda> machine), and is trivial to implement (and it still has all the
joda> features we want).

XDR is likely more useful than ASN.1 for many things,  though I
suspect that there may be some existing sentiment against XDR due to
its use in RPC, which people may dislike due to security holes in its
implementations.  For what it's worth, I don't think that I've found
many security problems in XDR, and the bulk of the nasty bugs I've
found have been within the RPC framework itself or within the
implementations of RPC services.

joda> You're right, I must have completely missed that. Anyhow I'm not
joda> sure it's a good idea to start using UTF-8 here, if the rest of
joda> the Kerberos standard is using 10646 (I believe this is the
joda> implication of the use of GeneralString, right?).

It's worse than that.  GeneralString isn't ISO-10646.  It's ISO-2022,
I believe, with associated things like 7 or 8 bits of encoding per
character, locking and non-locking shifts, G0, C0, G1, C1, etc.  Just
think back to the way VT100 terminals handle character sets.  yuck.

I believe there's a movement to use UTF8String tagged as GeneralString
for the 1510 revision, though the notation "[UNIVERAL 27] IMPLICIT
UTF8String" isn't compliant, technically.

I think the original idea was to use UniversalString or BMPString
which are ISO-10646, but someone perhaps got confused with the
plethora of character string types in ASN.1.  *sigh*

---Tom

---

From: Mike Eisler <[email-masked]>
Date: Wed, 8 Mar 2000 13:54:57 -0800 (PST)

> are attempts at simpler interfaces.

It's more complex than a protocol to let admin or users change a user's
password, which in turn is more complex than a protocol to let a user change
his own password. It also is complete solution.

The set-passwd protocol is simply a step down the road to more remote
administration. If an admin wants to set a password, won't he also want to
set other attributes of a principal? If so, will he use the proposed
protocol, or will he used whatever proprietary protocol his vendor (possibly
based on or equal to the MIT protocol) the system vendor provides?

> [...] and at least somewhat undocumented. 

So document it, or something that else that is equivalent.

	-mre

	-mre

---

From: Geoff Elgey <[email-masked]>
Date: Thu, 09 Mar 2000 07:57:11 +1000

G'day,

> release certain documents that IETF standards depend on for free to

I agree about the standards not being freely available -- I
*desparately* need to look at the semantic model for ASN.1 types (as
type equivalency is not defined in the latest X.680 specification), and
that document is only available "for subscription holders only". Here's
my credit card, there's the document, but I cannot get it. I've got a
good idea about what's in the semantic model, but no way of confirming
it unless I get a subscription to the ITU-T :-( 

There's also the issue of some parts of the specification being "a guide
to tool implementors", rather than being clearly defined (as I have
since found out).

I'm trying to wrangle an airfare to Geneva for the next ASN.1 standards
meeting, and I will (hopefully) be raising the points you mention
(especially about protocols being written by people who have no real
understanding of the standards, as the standards cost money).

There is a downloadable ASN.1 textbook available though -- John
Larmouth's "ASN.1 Complete" (see
http://www.nokalva.com/asn1/larmouth.html) which supplements the
X.680-X.683 specifications quite well. However, it does not mention how
to avoid the "common pitfalls" of using ASN.1. Publishing a document on
this topic is an excellent idea.

Cheers,
Geoff

---

From: Tom Yu <[email-masked]>
Date: 08 Mar 2000 17:21:53 -0500

following up to my own post. :-)

>>>>> "tlyu" == Tom Yu <[email-masked]> writes:

tlyu> For what it's worth, I don't think that I've found many security
tlyu> problems in XDR

Sorry, I meant I don't think I've found *any* security problems in
XDR, but I haven't looked all that closely yet.

---Tom

---

From: Ken Raeburn <[email-masked]>
Date: 08 Mar 2000 21:07:09 -0500

Mike Eisler <[email-masked]> writes:

>> [...kadmin protocol...]

Taking the kadmin code, regenerating a .x file for it, and putting it
on top of RPCSEC_GSS might be a good start for standardizing an admin
protocol.

> set other attributes of a principal? If so, will he use the proposed

This is why I'd be opposed to the set-passwd changes.  The
change-passwd spec as is fills a gap required by the basic Kerberos
protocol (the "must change password" response); it's not a remote
administration tool.  Well, maybe it's borderline, but set-passwd is
clearly on the admin-tool side, and not directly needed by anything in
the core protocol.  Let's do it right, and not tack it on the side of
the basic change-passwd protocol.

Maybe we could alter the change-passwd spec to support other
administrative functions, but it needs to have the right extensibility
hook, which IIRC it didn't.  (But I'm on a bad net connection at
connectathon right now and can't easily check, sorry.)  I don't think
altering it to support *one* admin function, and still requiring a
separate protocol for the others, makes much sense.

Ken

---

From: Tom Yu <[email-masked]>
Date: 08 Mar 2000 22:40:17 -0500

>>>>> "elgey" == Geoff Elgey <[email-masked]> writes:

elgey> I'm trying to wrangle an airfare to Geneva for the next ASN.1
elgey> standards meeting, and I will (hopefully) be raising the points
elgey> you mention (especially about protocols being written by people
elgey> who have no real understanding of the standards, as the
elgey> standards cost money).

You know, this is one thing that the supposed new alliance between the
IETF and the ITU-T should help with, in theory. :-)  I really wish
that some practical benefit would arrise from the cooperation of the
IETF and the ITU-T.

elgey> There is a downloadable ASN.1 textbook available though -- John
elgey> Larmouth's "ASN.1 Complete" (see
elgey> http://www.nokalva.com/asn1/larmouth.html) which supplements
elgey> the X.680-X.683 specifications quite well. However, it does not
elgey> mention how to avoid the "common pitfalls" of using
elgey> ASN.1. Publishing a document on this topic is an excellent
elgey> idea.

I have skimmed John Larmouth's book, which seems to be reasonably well
written.  I am in the process of writing up a document describing the
common pitfalls that I have encountered in the use of ASN.1 in IETF
protocols.  Hopefully I can get it in before the draft cut-off for
Adelaide.

---Tom

---

From: [email-masked] (Johan Danielsson)
Date: 09 Mar 2000 10:27:43 +0100

> this topic is an excellent idea.

It's also more of a technical overview than a document you can use to
implement anything. It only helps you a small amount if you want to
implement a ASN.1 parser.

/Johan

---

From: [email-masked] (Johan Danielsson)
Date: 09 Mar 2000 10:23:19 +0100

Ken Raeburn <[email-masked]> writes:

> administration tool.

I agree.

Are you (as in someone at MIT) going to brush up the OV kadmin spec
and submit it as a draft?

/Johan

---

From: "David A. McGrew" <[email-masked]>
Date: Thu, 09 Mar 2000 08:03:27 -0800

Tom,

> projects and open-source code.

from http://oscar.dstc.qut.edu.au/

"DSTC modified version of SNACC released.  We have released a modified
version of the SNACC ASN.1 compiler which supports Big Integers and DER.
This compiler has been released under the GPL and is available for
download."

This work was done so that SNACC could support X.509.  

> kenh> Kerberos that ended with the line, "Friends don't let friends

I'd be interested in seeing that message.  Is there a web archive of
this list that is available?

thanks,

David
[email-masked]