From: [email-masked]
Date: Wed, 13 Nov 2002 13:18:50 -0600 (CST)

gADHKfOq006477;
	Wed, 13 Nov 2002 10:20:41 -0700 (MST)
Date: Wed, 13 Nov 2002 11:20:40 -0600
From: Nicolas Williams <[email-masked]>
To: Sam Hartman <[email-masked]>
Cc: Ken Raeburn <[email-masked]>, [email-masked]
Subject: Re: some comments on newest kerberos-clarifications
Mail-Followup-To: Sam Hartman <[email-masked]>,
	Ken Raeburn <[email-masked]>, [email-masked]
<[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[email-masked]>; from [email-masked] on Tue, Nov 12,
2002 at 05:06:32PM -0500
X-Spam-Status: No, hits=-102.3 required=6.0
	tests=IN_REP_TO,DOUBLE_CAPSWORD,USER_IN_WHITELIST
	version=2.31
Sender: [email-masked]
Precedence: bulk

On Tue, Nov 12, 2002 at 05:06:32PM -0500, Sam Hartman wrote:
> >>>>> "Nicolas" == Nicolas Williams [RU-CENTRAL] <Nicolas> writes:
>     Nicolas>  - Are KDCOptions critical? I think they ought to be.
> 
> 
> No, and I think we have consensus on this and I believe the text in
> section 2 is clear on this point.
> 
> If a client wants an option to be treated as critical it should reject
> the response if the option is not honored.
> 
> You only really need criticality when you have an exchange where the
> party that cares about criticality will not have an opportunity to see
> whether the option is understood.

Oh, I remember now. Got it. Thanks.

>     Nicolas>  - Sections 5.2.7.4 and 5.2.7.5, paragraph 1, first
>     Nicolas> sentence, read "is sent" whereas MUST/SHOULD/MAY ought to
>     Nicolas> be used.  Only one of PA-ETYPE-INFO/PA-ETYPE-INFO2 can be
>     Nicolas> sent in KRB-ERROR, unless Typed-Data is used (but
>     Nicolas> Typed-Data is not to be used for KDC_ERR_PREAUTH_REQUIRED
>     Nicolas> errors).  See above.  Requires clarification.
> 
> No, both can be sent.  The edata for preauth required is sequence of
> padata.

Well, yes, both can be sent, but for pre-etype-info2 enctypes etype-info
ought to be sent for those enctypes regardless of whether etype-info2
entries are also sent for the same enctypes.

My complaint was that the draft says "such and such is sent" instead of
"such and such MUST be sent in cases where ..." and that 'MUST' ought to
be used to require the use of etype-info for older enctypes.

Re-reading the draft I see that between section 8.1 and the last
paragraph of section 5.2.7.5 my concerns are mostly taken care of.
Section 8.1 mandates support for etype-info2 and recommends support for
etype-info for interop with older client implementations.

Cheers,

Nico
--