Subject: [apps-discuss] APPSDIR review of draft-ietf-kitten-gssapi-naming-exts-14

From: William Mills <[email-masked]>
Date: Tue, 17 Apr 2012 13:16:17 -0700 (PDT)

Document:             draft-ietf-kitten-gssapi-naming-exts-14
Title:                GSS-API Naming Extensions
Reviewer:             William J. Mills
Review Date:          April 17, 2012
IETF Last Call Date:  N/A
IESG Telechat Date:   N/A

Summary: This draft is nearly ready for publication, some corrections are suggested.

Major Issues: 

Section 5, 9th paragraph:  The first sentence is not declarative enough, "Local implementations or platforms are likely to have sufficient policy and information to know when contexts can be treated as the same.", I'd prefer changing "Are likely" to "MUST", and then add "and MUST NOT assume different attributes are equivalent" at the end of that sentence.  

Minor Issues: 

Section 7.6, last paragraph: strike "; this has been discussed on the KITTEN WG mailing list and the consensus seems to be that, indeed, that was always the intention".  It's not required to note WG consensus, and this is implicit in document adoption.

Generally:  I wonder at the choice of not including ABNF for things like attribute name, since you're defining a syntax here.  It's well enough defined in the text, but I generally think of parseable syntax as being more explicitly defined with ABNF.

Nits: 

Section 3, 3rd paragraph: "follows.This"needs spaces.

Section 9, 3rd para: "asserte" needs a "d".  "Any additional semantics is always the result of applying policy.", change "is" to "are".

---

From: William Mills <[email-masked]>
Date: Tue, 17 Apr 2012 13:25:22 -0700 (PDT)

(Resend to the correct addresses)

Major Issues: 

Section
 5, 9th paragraph:  The first sentence is not declarative enough, "Local
 implementations or platforms are likely to have sufficient policy and 
information to know when contexts can be treated as the same.", I'd 
prefer changing "Are likely" to "MUST", and then add "and MUST NOT 
assume different attributes are equivalent" at the end of that 
sentence.  

Minor Issues: 

Section 7.6, last 
paragraph: strike "; this has been discussed on the KITTEN WG mailing 
list and the consensus seems to be that, indeed, that was always the 
intention".  It's not required to note WG consensus, and this is 
implicit in document adoption.

Generally:  I wonder at the choice
 of not including ABNF for things like attribute name, since you're 
defining a syntax here.  It's well enough defined in the text, but I 
generally think of parseable syntax as being more explicitly defined 
with ABNF.

Nits: 

Section
 9, 3rd para: "asserte" needs a "d".  "Any additional semantics is 
always the result of applying policy.", change "is" to "are".

---

From: Sam Hartman <[email-masked]>
Date: Tue, 17 Apr 2012 16:36:26 -0400

>>>>> "William" == William Mills <[email-masked]> writes:

    William> Major Issues:

    William> Section 5, 9th paragraph: The first sentence is not
    William> declarative enough, "Local implementations or platforms are
    William> likely to have sufficient policy and information to know
    William> when contexts can be treated as the same.", I'd prefer
    William> changing "Are likely" to "MUST", and then add "and MUST NOT
    William> assume different attributes are equivalent" at the end of
    William> that sentence.

I'm confused when I read the above proposed change because I don't
actually understand its affect.

I'm generally against the change because I think the current text
actually describes the reality of the situation. I think the proposed
text describes something else, and I'm not sure that something else is
actually a true statement about how implementations will behave.
So, I'd like to understand your proposal better.

---

From: William Mills <[email-masked]>
Date: Tue, 17 Apr 2012 13:42:09 -0700 (PDT)

The key of this for me is "are likely to have sufficient policy and information".  This is fine in discussion, but I want to see an explicit declaration about when an implementation can treat things as equivalent.

-bill

>________________________________
> From: Sam Hartman <[email-masked]>
>To: William Mills <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]>; [email-masked]; The IESG <[email-masked]> 
>Sent: Tuesday, April 17, 2012 1:36 PM
>Subject: Re: Resending: APPSDIR review of draft-ietf-kitten-gssapi-naming-exts-14
>

---

From: Sam Hartman <[email-masked]>
Date: Tue, 17 Apr 2012 16:48:00 -0400

>>>>> "William" == William Mills <[email-masked]> writes:

    William> The key of this for me is "are likely to have sufficient
    William> policy and information".  This is fine in discussion, but I
    William> want to see an explicit declaration about when an
    William> implementation can treat things as equivalent.

I don't think we can say anything about that. Implementations can treat
things as equivalent when they know that it's safe to do so through
policy which may be hard-coded, configured or downloaded from somewhere.
I think that's an implementation matter outside the scope of the
standard.

---

From: Nico Williams <[email-masked]>
Date: Tue, 17 Apr 2012 20:11:26 -0500

> I think that's an implementation matter outside the scope of the

I agree.  I suspect Bill is concerned that lacking "sufficient policy
and information" may lead to vulnerabilities, say, in that critical
attributes may get ignored.  We have no method for indicating
attribute criticality in the proposed API, and this is by design.
Mechanisms may (and Kerberos, for example, does) have methods for
indicating attribute criticality.  What must happen is that systems
must know how to interpret critical mechanism attributes, but this is
already required by mechanism specifications.  So I think we're
covered, but perhaps we could make this a little more explicit.

Nico
--

---

From: William Mills <[email-masked]>
Date: Tue, 17 Apr 2012 18:23:58 -0700 (PDT)

OK, if this is covered by the mechanisms (which is something a GSS expert probably knows but I did not) then I'm less worried.  Is it then worthwhile to add "Systems must know how to interpret critical mechanism attributes, but this is already required by mechanism specifications." in the section we're talking about to make it explicit rather than implicit?

-bill

> From: Nico Williams <[email-masked]>
>To: Sam Hartman <[email-masked]> 
>Cc: William Mills <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; The IESG <[email-masked]> 
>Sent: Tuesday, April 17, 2012 6:11 PM
>Subject: Re: [apps-discuss] Resending: APPSDIR review of draft-ietf-kitten-gssapi-naming-exts-14
>

---

From: Nico Williams <[email-masked]>
Date: Tue, 17 Apr 2012 22:33:40 -0500

On Tue, Apr 17, 2012 at 8:23 PM, William Mills <[email-masked]> wrote:
> OK, if this is covered by the mechanisms (which is something a GSS expert
> probably knows but I did not) then I'm less worried.  Is it then worthwhile
> to add "Systems must know how to interpret critical mechanism attributes,
> but this is already required by mechanism specifications." in the section
> we're talking about to make it explicit rather than implicit?

Yes.  I like the conciseness of the text you propose.  The I had in
mind was something like this:

   The manner in which name attributes are conveyed by GSS
   mechanisms is mechanism-specific.  If a GSS mechanism
   provides a way to indicate criticality then local policy MAY
   require that any given GSS name attribute be expressed using
   critical elements of the mechanism.  However, criticality is not
   exposed in this API because criticality is intended to be handled
   by local policy and the mechanisms.  This means that a system
   that lacks local policy by which to deal with critical mechanism
   elements conveying name attributes should fail security context
   establishment when such critical elements are used by the
   peer.

That's quite a mouthful, so I tend to prefer your text.

Nico
--

---

From: William Mills <[email-masked]>
Date: Tue, 17 Apr 2012 21:19:44 -0700 (PDT)

Now see, now I feel obligated to point out I was quoting you, I just capitalized the S at the front.

>Cc: Sam Hartman <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; The IESG <[email-masked]> 
>Sent: Tuesday, April 17, 2012 8:33 PM

---

From: Nico Williams <[email-masked]>
Date: Tue, 17 Apr 2012 23:21:48 -0500

> capitalized the S at the front.

Oh, heh.  Well, that shows how much attention I was paying!

---

From: Sam Hartman <[email-masked]>
Date: Thu, 19 Apr 2012 09:11:07 -0400

>>>>> "William" == William Mills <[email-masked]> writes:

    William> OK, if this is covered by the mechanisms (which is
    William> something a GSS expert probably knows but I did not) then
    William> I'm less worried.  Is it then worthwhile to add "Systems
    William> must know how to interpret critical mechanism attributes,
    William> but this is already required by mechanism specifications."
    William> in the section we're talking about to make it explicit
    William> rather than implicit?

I'm now even more confused.
I definitely don't understand how this discussion is about criticality
of attributes.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 19 Apr 2012 09:49:39 -0400

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico>    The manner in which name attributes are conveyed by GSS
    Nico> mechanisms is mechanism-specific.  If a GSS mechanism provides
    Nico> a way to indicate criticality then local policy MAY require
    Nico> that any given GSS name attribute be expressed using critical
    Nico> elements of the mechanism.  

What?
I'm not sure I'd expect local policy to be where that gets decided.

    Nico> However, criticality is not
    Nico> exposed in this API because criticality is intended to be
    Nico> handled by local policy and the mechanisms.  

I disagree with the part of that sentence after because.
I don't think we have consensus on why criticality is not part of the
API.

    Nico> This means that a
    Nico> system that lacks local policy by which to deal with critical
    Nico> mechanism elements conveying name attributes should fail
    Nico> security context establishment when such critical elements are
    Nico> used by the peer.

    Nico> That's quite a mouthful, so I tend to prefer your text.

Probably true but I don't see how this relates to the previous text nor
that it is appropriate to add this text to the document at this point in
the process.

---

From: William Mills <[email-masked]>
Date: Thu, 19 Apr 2012 08:58:18 -0700 (PDT)

What I am focused on is when attributes are taken to be equivalent.  Not that they themselves are, but there are security implications if you get it wrong.

>Cc: Nico Williams <[email-masked]>; Sam Hartman <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; The IESG <[email-masked]> 
>Sent: Thursday, April 19, 2012 6:11 AM

---

From: Nico Williams <[email-masked]>
Date: Thu, 19 Apr 2012 11:53:51 -0500

> I don't think we have consensus on why criticality is not part of the

Indeed, but criticality is still an existing feature of mechanisms.

Obviously a critical element in a ticket or certificate or whatever
still needs to be handled correctly, even if the API has no way to
indicate it (although we can indicate so much via just the name of the
attribute...).  That's obvious enough.  The implication is that any
policy mapping such an element to a name attribute has to exist and be
sufficient to satisfy the criticality of the mechanism element.

But when a system wants to set a mechanism element corresponding to a
given attribute name, how should the system decide whether that
mechanism element is to be flagged as critical?  Only local policy (or
hardcoding, or deriving criticality from the attribute name/prefix)
can do that given that the API lacks a way to request or indicate
criticality.

To me all that goes without saying.  It seems obvious.  The
alternative is to say that none of these name attributes map to
critical mechanism elements, but the first part (how to deal with
receiving critical elements) remains.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 19 Apr 2012 19:29:44 -0400

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico> Indeed, but criticality is still an existing feature of
    Nico> mechanisms.

    Nico> Obviously a critical element in a ticket or certificate or
    Nico> whatever still needs to be handled correctly, even if the API
    Nico> has no way to indicate it (although we can indicate so much
    Nico> via just the name of the attribute...).  That's obvious
    Nico> enough.  The implication is that any policy mapping such an
    Nico> element to a name attribute has to exist and be sufficient to
    Nico> satisfy the criticality of the mechanism element.

I think the question of how acceptors handle critical elements is open
and has never been discussed.
Thus is inappropriate to discuss at this point for this document.

I'd guess you'd want some API that indicated before accept_sec_context
time what critical elements you as an acceptor handle.
Or absent such an API do it through policy, but that seems kind of
dreadful.

I think the question of how to flag an element as critical in a name
attribute  is dependent on the mechanism--that is documents like
draft-ietf-abfab-gss-eap-naming for mechanisms that have critical
attributes need to cover that.
I.E. that question would be covered in a document describing how
Kerberos uses name attributes.

I think local policy is a singularly bad place to make that distinction,
although I agree we could do that.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 19 Apr 2012 20:19:36 -0400

Spoke to Nico on the phone.
I'm basically happy with his style of text if rather than policy we say
policy and code.