Subject: partial review of draft-ietf-krb-wg-kerberos-set-passwd-05.txt

From: Love Hörnquist Åstrand <[email-masked]>
Date: Fri, 12 Jan 2007 00:47:19 +0100

I think the protocol is way to complicated. This is going to take a
long time for me to wrap my head around all this.

This is my initial comments after trying to read this for an hour,
I've still not manged to read thought the whole document.

1.1 ---------------------

Any comments that are longer then 4 lines in the ASN.1 module is a
sign that something is sick, esp if I can't find any text in the
module about how its supposed to work.

1.2 ---------------------

What is "transited encoding data types" and why does the server need
to optimise for it

1.3 ---------------------

ProtocolErrorCode --
"   The protocol error codes are:"

     thanks, but what do they mean, and when should they be sent ?

1.4 ---------------------

"
    Servers MUST respond with an error (ProtocolErrorCode value of
    unsupported-minor-version) to clients that use operations unknown to
    the server.
"

but the ProtocolErrorCode ENUM SAY

         proto-unsupported-operation,      -- Request CHOICE tag unknown

which should I use ?

1.5 -------------------

"(1..)" is used here and there, its that valid asn.1 ? Shouldnä't that
be (1..MAX) ?

1.6 -------------------

Why is ETYPE-INFO2 rename to Etype-Info-Entry ?

1.7 -----------------

       Req-get-s2kparams() ->
          Rep-get-s2kparams([princ-s2kparams], [preferred-s2kparams])

[...]
    Rep-get-s2kparams            ::= SEQUENCE {
         help-text       [0] UTF8String OPTIONAL,
         s2kparams       [1] SEQUENCE OF Etype-Info-Entry,
         ...
    }

How does this match, what is princ-s2kparams and what is
preferred-s2kparams ?

Why is the component name s2kparams ? Its not, is a SEQ OF etype-info
element.

1.8 --------------------

Please define extentions via type-ed holes { value, octet-string },
not asn1 extentions.

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 18 Jan 2007 23:17:12 -0600

> long time for me to wrap my head around all this.

Well, I tried to organize it so the individual components can be easily
reviewed one at a time.

Do you have advice on how I can make it easier, or are you saying that
any protocol of this sort will be too complicated, or that this
particular design is too complicated, and if so, what makes it so
complicated (ASN.1?)?

> I've still not manged to read thought the whole document.

OK, thanks.

Or that they are misplaced and should be moved into the main text of the
document.

See RFC4120.

Their names were intended to be self-explanatory, but I'll add text.

Ugh.  I'll fix that to say proto-unsupported-operation.

Indeed.

No real reason.

Er, I think this is an editing error, and I don't recall what the
purpose of this was.

> Why is the component name s2kparams ? Its not, is a SEQ OF etype-info

In the ASN.1 that's what it is.  The description in section 3.2.11 needs
to be updated.

This is a good point.  And there is a suitable typed hole already (since
the protocol is organized in an RPC-like fashion).  I won't mind
removing most of the extensibility markers.

Nico
--