draft-zhu-kerb-enctype-nego-03.txt

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

draft-zhu-kerb-enctype-nego-03.txt

Kenneth G Raeburn
Just minor stuff:


> Updates: 4120 (if approved)

"if approved" isn't needed; any I-D that doesn't get approved doesn't
update anything.

Page 3:

>    If the client prefers an enctype over that of the service ticket
>    session key, then it sends the list of enctypes it supports
>    (including the one selected by the KDC) in decreasing preference
>    order.

Perhaps this should also say, "and it is expected that the server may
return an AP-REP message with a subkey", thus phrasing the conditions
in positive form and up front.  Then we wouldn't need:

>    This negotiation extension SHOULD NOT be used when the client does
>    not expect the subkey in the AP-REP message from the server.

... to partially negate the applicability of this extension.

>    A note on key generation: The KDC has a strong Pseudo-Random Number

s/has/is expected (or assumed) to have/ ?

I don't think RFC 4120 actually says MUST, although we do talk about
"cryptographic principles" and true random number sources.

>    Generator (PRNG), as such the client can take advantage of the

I don't think "as such" works here.  Try "so", or "thus" with a
preceding semicolon or as a separate sentence.

>    The server MAY ignore the preference order indicated by the client.
>    The policy by which the client or the server chooses an enctype
>    (i.e., how the preference order for the supported enctypes is
>    selected) is a local matter.

Given that so far we've said nothing about the server using the order
indicated by the client, perhaps "MAY use" would be better.  Otherwise,
I like this text better than the old.  (Sorry I didn't respond to your
proposal of it earlier.)

Ken