Subject: Re: [kitten] WGLC for three "bis" documents: draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01, draft-ietf-kitten-rfc6112bis-00

From: Greg Hudson <[email-masked]>
Date: Sun, 01 Feb 2015 16:49:15 -0500

On 01/20/2015 06:02 PM, Benjamin Kaduk wrote:
> http://tools.ietf.org/html/draft-ietf-kitten-rfc4402bis-00

I reviewed this and did not find any problems with it.

> http://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-01

My only substantive note is that the InputStream/OutputStream forms of
initSecContext/acceptSecContext could, perhaps, already write tokens to
the outStream parameter before throwing an exception, instead of
communicating them in the exception.  If this issue has already been
discussed, please ignore this remark.  If not, I suspect it might be
easier on callers (but perhaps harder on implementations) just to
require that callers flush or otherwise handle content in the output
stream after an exception.  I do not have a strong interest in how this
turns out, though.

Some text was removed from the copyright notice about containing
pre-2008 material.  If this was intentional, please ignore this remark.

In several places the draft uses the new text "to inform the reason for
the error," which is not correct English.  I suggest "to communicate the
reason for the error."

The section 5.2 table contains the pre-existing typo "Covert" for
"Convert".  I noticed because the table was reformatted; it may or may
not be worth correcting.

> http://tools.ietf.org/html/draft-ietf-kitten-rfc6112bis-00

I found a typo: "optionSHOULD" for "option SHOULD."

---

From: Weijun Wang <[email-masked]>
Date: Mon, 02 Feb 2015 11:03:01 +0800

> stream after an exception.  I do not have a strong interest in how this

The main reason I preferred the current design is to be consistent with 
the byte array forms of the methods, which gives the caller the chance 
to determine whether the error token should be sent or not.

> pre-2008 material.  If this was intentional, please ignore this remark.

The whole Copyright Notice section is automatically generated by 
xml2rfc. I thought that paragraph is a standard part of every old RFC 
and the new format should override it. If not, I'll add it back (I'll 
have to figure out where to add it in the XML file).

> the error," which is not correct English.  I suggest "to communicate the

OK.

> "Convert".  I noticed because the table was reformatted; it may or may

I've correct it.

Thanks
Weijun

> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 2 Feb 2015 11:28:35 -0500 (EST)

On Sun, 1 Feb 2015, Weijun Wang wrote:

> The whole Copyright Notice section is automatically generated by xml2rfc. I
> thought that paragraph is a standard part of every old RFC and the new format
> should override it. If not, I'll add it back (I'll have to figure out where to
> add it in the XML file).

I believe this is the 'ipr' attribute of the <rfc> tag at the beginning of
the document, per https://tools.ietf.org/html/rfc2629#section-2.2.7.1 --
unfortunately, that RFC does not document all the possible values listed
in the DTD, and the DTD itself
(http://www.w3.org/2008/xmlsec/Drafts/algorithms-rfc/rfc2629.dtd ?)
doesn't offer much guidance about what each value does.

-Ben

---

From: Weijun Wang <[email-masked]>
Date: Tue, 03 Feb 2015 09:51:47 +0800

But the xml2rfc tool claims

    No boilerplate text available for ipr: 'full2026'.  Acceptable 
values are: trust200902, noModificationTrust200902, 
noDerivativesTrust200902, pre5378Trust200902, trust200811, 
noModificationTrust200811, noDerivativesTrust200811

I decide to choose "pre5378Trust200902". The output text is almost 
identical to that of RFC 5653, but adding these lines which I think is 
harmless

        Code Components extracted from this document must
    include Simplified BSD License text as described in Section 4.e of
    the Trust Legal Provisions and are provided without warranty as
    described in the Simplified BSD License.

Thanks
Max

On 2/3/2015 0:28, Benjamin Kaduk wrote:
> the document, perhttps://tools.ietf.org/html/rfc2629#section-2.2.7.1  --

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 4 Feb 2015 00:15:07 -0500 (EST)

Just a reminder: two weeks remain in this WGLC period.

-Ben

On Thu, 29 Jan 2015, Benjamin Kaduk wrote:

> Just under three weeks remain in this WGLC period.
>
> -Ben
>
> On Tue, 20 Jan 2015, Benjamin Kaduk wrote:
>
> > This message begins the Working Group Last Call (WGLC) for the following
> > three documents: "A Pseudo-Random Function (PRF) for the Kerberos V
> > Generic Security Service Application Program Interface (GSS-API)
> > Mechanism" <draft-ietf-kitten-rfc4402bis-00>, "Generic Security Service
> > API Version 2: Java Bindings Update" <draft-ietf-kitten-rfc5653bis-01>,
> > and "Anonymity Support for Kerberos" <draft-ietf-kitten-rfc6112bis-00>.
> > Because there are three documents under review, and the whole body of the
> > documents are up for re-review (not just the updates), the WGLC is
> > extended to four weeks, so the WGLC will end on Tuesday February 17th,
> > 2015.  The drafts are available at:
> >
> > Please review these documents and send comments to the Working Group
> > mailing list [email-masked] or the co-chairs
> > <[email-masked]> before the end of the WGLC.  Any and all
> > comments on the document(s) are sought in order to assess the strength of
> > consensus.  Even if you have read and commented on this or earlier
> > versions of the draft, please feel free to comment again.  This is
> > particularly important if you found issues with the previous version.
> >
> > As a reminder, comments can be anything from "this looks fine" to "this is
> > a horrible idea"; they can include suggestions for minor editorial
> > corrections to significant editorial changes.
> >
> >
> > - Your Kitten Chairs
> >

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 5 Feb 2015 00:14:53 -0500 (EST)

On Mon, 2 Feb 2015, Weijun Wang wrote:

>    No boilerplate text available for ipr: 'full2026'.  Acceptable values are:
> trust200902, noModificationTrust200902, noDerivativesTrust200902,
> pre5378Trust200902, trust200811, noModificationTrust200811,
> noDerivativesTrust200811

The standalone tool for local use, or http://xml2rfc.ietf.org/ ?  I think
that at least at one point, they had slightly different behavior.

> I decide to choose "pre5378Trust200902". The output text is almost identical
> to that of RFC 5653, but adding these lines which I think is harmless
>

That may be good enough; we can call out the difference in the shepherd
report and/or RFC Editor note if needed.

-Ben

---

From: Weijun Wang <[email-masked]>
Date: Thu, 05 Feb 2015 13:17:09 +0800

Hi Greg

> to determine whether the error token should be sent or not.

Are you OK with this reason?

Thanks
Weijun

---

From: Weijun Wang <[email-masked]>
Date: Thu, 05 Feb 2015 13:35:44 +0800

> that at least at one point, they had slightly different behavior.

Local, but the web tool also shows the same error. In fact, there is a 
box on the web page explaining several ipr values (4 flavors of 
trust200902) and "pre5378Trust200902" seems to be the correct one since 
the initial RFC for JGSS-API (RFC 2478) was submitted in June 2000.

> report and/or RFC Editor note if needed.

I am waiting for feedback from Greg, and after that I'll post -02 draft.

Thanks
Weijun

---

From: Greg Hudson <[email-masked]>
Date: Thu, 05 Feb 2015 02:17:33 -0500

> Are you OK with this reason?

As I said, I don't have a strong opinion either way, but I'm not sure
why it would be important or useful to give the caller a chance to
decline to send an error token.

---

From: Weijun Wang <[email-masked]>
Date: Thu, 05 Feb 2015 15:46:24 +0800

> decline to send an error token.

The current implementation does not send the error token (This is not 
precisely specified although the doc does mention that a token generated 
by initSecContext/acceptSecContext is meant to be consumed by 
acceptSecContext/initSecContext by the peer). Either a caller does not 
want to send the token at all, or one should have already written extra 
code to generate that token and send it.

If we now silently send the token, it will be a big behavior change and 
a surprise for everyone.

Thanks
Weijun

---

From: Bill Mills <[email-masked]>
Date: Thu, 5 Feb 2015 14:54:58 +0000 (UTC)

The standalone tool can product results that the more aggressive parser in the submission checked won't accept.  I use that for local work but always submite the XML to the online tool for final production of the plaintext draft. 

     On Wednesday, February 4, 2015 9:35 PM, Weijun Wang <[email-masked]> wrote:

Thanks
Weijun

---

From: Greg Hudson <[email-masked]>
Date: Thu, 05 Feb 2015 11:06:59 -0500

> code to generate that token and send it.

Error tokens are usually consumed by accept/init on the peer.  The
exception is if the peer is already in the GSS_S_COMPLETE state, in
which case it needs to be consumed by gss_process_context_token.

I don't think it's legitimate for a GSS application to decide to discard
a token simply because it came with an error return.  If the application
knows that the other peer is in GSS_S_COMPLETE state and the protocol
has no way of framing a context token to a peer in that state, then it
has no choice to discard the token.  But absent that specific knowledge,
the token should always be sent.

> If we now silently send the token, it will be a big behavior change and

As an implementor I certainly understand wanting to be conservative
about surprising applications.  I don't know how likely it is that Java
applications would break if tokens started showing up in the output
stream when init/accept raises an error.

On the flip side, making the caller explicitly retrieve the token is
likely to result in a lot of applications which don't bother.  That's
unavoidable for the byte array methods, but not for the stream methods.

(As an aside, I believe the Python bindings plan to solve this by
raising an exception for the GSS_S_CONTINUE case as well as for errors,
so an application needs code to extract a token from an exception in
order to work for anything more than a single hop.)

---

From: [email-masked] (Martin Rex)
Date: Fri, 6 Feb 2015 00:54:18 +0100 (CET)

> the token should always be sent.

I'm sorry to disagree, but I believe that the opposite applies.

GSS-API does *NOT* define a wire protocol, only a wire token format.
It is *ENTIRELY* up to the application to decide about whether and how
to embed and send GSS-API tokens .. or not.

It is perfectly OK for an application to discard a context level token
from a gssapi mechanism that is returned along with a fatal major_status
from the context iterator call -- *unless* the specific application wire
protocol explicitly requires a different behaviour[*].

Since it requires additional application protocol complexity and additional
application code (calling of gss_process_context_token) to process
"unexpected" context token in an application protocol, it is *MUCH* easier
to unconditionally discard context level tokens from a context iterator
call that accompany a fatal major_status code.

A "portable" application caller does not know whether such a token
will be "unexpected" for the peer, so conveying such a token without
knowing whether the peer will be capable of dealing gracefully with it
is somewhat "risky".  My application code will never convey context error
tokens, I will not contemplating ever conveying error tokens, and I've
NEVER had a situation where this decision was detrimental during the
past 19 years where we've been using GSS-API to protect our application's
communication for our proprietary communication protocols.

-Martin

  [*] SSL&TLS define a wire protocol and specify certain behaviour in
  addition to protocol PDUs.  Microsoft implemented SSL&TLS with a GSS-API
  style interface: The Microsoft SChannel SSP, and the application caller
  "Microsoft IIS" unfortunately follows the proprietary apps protocol
  approach and discards error tokens, rather than sending fatal TLS alerts
  to the peer, as the TLS protocol _requires_ it.

---

From: Weijun Wang <[email-masked]>
Date: Fri, 06 Feb 2015 08:04:14 +0800

On 2/6/2015 0:06, Greg Hudson wrote:
> Error tokens are usually consumed by accept/init on the peer.

I was wrong about that.

> stream when init/accept raises an error.

It should not break. The peer might have been a non-Java app and is 
already sending that token.

One problem is that if the app "have already written extra code to 
generate that token and send it", now it will send it twice.

> unavoidable for the byte array methods, but not for the stream methods.

Stream methods are not used by many. So most people would have to 
rewrite their apps to make use of this feature.

Thanks
Max

---

From: Greg Hudson <[email-masked]>
Date: Thu, 05 Feb 2015 19:40:10 -0500

> generate that token and send it", now it will send it twice.

How would an app generate its own GSSAPI error token?  Surely it would
have to have intimate knowledge of the mech in order to do so.

> rewrite their apps to make use of this feature.

Fair enough.

If, considering all of the arguments given thus far, you still feel that
it's better for the stream methods to be consistent with the byte
methods, I don't have any strong objection to keeping it the way it is.

---

From: Weijun Wang <[email-masked]>
Date: Fri, 06 Feb 2015 08:51:26 +0800

> have to have intimate knowledge of the mech in order to do so.

I don't know if there exists an app doing that. Still possible. Maybe I 
am just looking for reasons to persuade myself. :-)

> methods, I don't have any strong objection to keeping it the way it is.

That's still my position. I just don't want to introduce a behavior change.

Thanks for all the advices. I'll prepare a -02 draft including other 
changes you suggested.

--Weijun

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 5 Feb 2015 23:19:12 -0500 (EST)

> protocol explicitly requires a different behaviour[*].

Exactly.

-Ben

---

From: Wang Weijun <[email-masked]>
Date: Fri, 6 Feb 2015 15:28:45 +0800

http://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-02 posted. Major diff is the pre-2008 paragraph in copyright notice. Others are a new date, 4 s/inform/communicate/ and one typo.

Thanks
Weijun

> On Feb 5, 2015, at 13:35, Weijun Wang <[email-masked]> wrote:
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 6 Feb 2015 18:13:19 -0500 (EST)

(was Re: [kitten] WGLC for three "bis" documents:
draft-ietf-kitten-rfc4402bis-00, draft-ietf-kitten-rfc5653bis-01,
draft-ietf-kitten-rfc6112bis-00)

[changing subject line to avoid complicating the threading if there are
discussions for the other two documents]

On Thu, 5 Feb 2015, Weijun Wang wrote:

> I don't know if there exists an app doing that. Still possible. Maybe I am
> just looking for reasons to persuade myself. :-)
>
> >

I got a chance to read more closely more of the bulk of the document.
(That is, read the whole text, not just the diff, though I skipped some
uninteresting API descriptions.)

First, I should note that the Java bindings explicitly do not implement
GSS_Process_context_token.  This does not directly affect any of the
reasoning about whether the application protocol can transmit
post-completion error tokens or the peer's ability to process them, since
the peer is not necessarily written in Java.

I have some serious concerns about the stream-based routines in general,
though.  Section 6.4.5 (and 6.4.9) contain the text:

          The GSS-API authentication tokens contain a definitive start and end.
          This method will attempt to read one of these tokens per invocation,
          and may block on the stream if only part of the token is available.

This is simply not true.  Only the initial context token is required to
use the ASN.1-like framing; subsequent context tokens are known to be from
a particular mechanism, and that mechanism can specify a token format
which does not contain framing information.  It happens that the Kerberos
and SPKM mechanisms mentioned in the introduction do use self-describing
token formats, but a generic mechanism is not bound to do so.  As
described in section 2 of
https://tools.ietf.org/html/draft-ietf-kitten-gss-loop-04 , the
application protocol using the GSS-API must specify how to frame and
identify context negotation tokens.

Similarly, the format of wrap tokens is mechanism specific, and is not
required to include framing information.  The discussion in 6.4.15 and
6.4.17 do not seem to include explicit claims that the wrap tokens are
self-describing, but the use of stream interfaces does tend to imply that
wrap() and unwrap() could be used to filter a data stream from an
application for encryption on the wire.

Because neither the context nor per-message tokens are required to be
self-describing, a generic GSS-API-using application protocol must specify
its own token framing, and the only safe way to use the stream forms of
these routines is to read the entire token from the network using the
application's framing, then construct a single-use stream for a single GSS
call, discarding the stream afterwards.  (It might be possible for an
application to limit itself to a specific mechanism which is known to use
token framing, but that completely loses the "Generic" part of "GSS-API".)
Since this essentially involves generating byte-array tokens everywhere
and generating single-use streams from them, it makes me wonder what
utility the stream forms of these routines provide.  That is, it seems
they could be removed from the specification, since they only increase the
programmer effort required, when used correctly.  However, I have no
experience writing GSS-API-using software in Java, so perhaps I am missing
something about how and why the stream forms might be preferred in some
cases.

Finally, I believe I can say a bit more about keeping the transmission of
error tokens under the application's control even when streams are used.

It seems that the intended workflow in section 7.4.5 of RFC 5653 is that
the initSecContext implementation will generate an output token and place
it into the OutputStream buffer; the application would then explicitly
call flush() on the stream to trigger the token transmission.  The
expectation would be that the stream provides complete buffering for each
token, so that each flush() or GSS call would transmit or consume exactly
one token on the stream.  Given the above commentary about non-framed
tokens, though, I don't see how this could work reliably.  In any case,
even in this model where the GSS implementation places bytes in the stream
to be flush()ed by the application, sections 7.4.5 and 7.4.9 of RFC 5653
are still ambiguous about whether the implementation places bytes in the
stream before throwing an exception.  A given implementation could either
place the token in the stream or not do so, and still be compliant with
what RFC 5653 specifies.

Since we are now discovering the issue, we should take advantage of the
opportunity to resolve the ambiguity, but are obligated to do so in a
backwards-compatible way.  It seems that erring on the side of not sending
error tokens is mroe backwards-compatible than erring on the side of
sending duplicate error tokens (though I have not given a great deal of
thought to it), so that would be my current preference.  That is, I think
Weijun is justified in his position of using an exception for error tokens
in the stream case.

A few other notes from my reading that probably do not affect the actual
specified behavior:

Comparing the descriptions of the initSecContext flavors in 6.4.3 and
6.4.5, it seems that the byte-array version's description in 6.4.3 started
out as a copy of the stream-based description in 6.4.5 and was not fully
updated for the byte-array case.  That is, it refers to "[t]his is
equivalent to the stream-based method except that the token buffers are
handled as byte arrays instead of using stream objects.", but the stream
version has not been introduced yet, so this is a forward reference that
is not marked as such.  It also has the text that "Typically, the
application would do so by calling the flush() method on an OutputStream
that encapsulates the connection between the two peers.", which does not
seem quite appropriate for a routine dealing in byte arrays.

The phrase "informational purpose" appears in three places in the new
text, but should be "informational purposes" with a trailing 's'.

RFC 5653 had a notice about the use of RFC 2119 keywords that is removed
in the current draft, which seems correct as I do not see any capitalized
RFC 2119 keywords in my reading.  I wonder how that notice slipped into
RFC 5653....

Section 6.8 of the -02 adds "For example, when an initSecContext call
fails due to a fatal error, the mechanism may define an error token [...]"
I wonder if "generate" might be better than "define".

In 6.8.2, I think that the text about the outputToken where "When
provided, the array will be cloned to protect against subsequent
modifications" could be more clear that the GSS implementation will make a
copy of the outputToken which was provided as input to the GSSException
constructor (as opposed to the copy being made at some later time).  In
particular, the word "clone" is a bit unusual to use here.

The unchanged text from RFC 5653 could also benefit from a general
copyediting pass, but I do not think I am prepared to perform one during
the WGLC period.

-Ben

---

From: Wang Weijun <[email-masked]>
Date: Tue, 10 Feb 2015 18:40:25 +0800

Hi Ben

> On Feb 7, 2015, at 07:13, Benjamin Kaduk <[email-masked]> wrote:
> 

I will spend some time talking with my colleagues on your opinions on stream-based methods. If we want to make any change on them, that will be much bigger than the current new GSSException method. I don't want to waste an RFC number if we have to modify the document again soon.

Thanks
Weijun

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 10 Feb 2015 16:16:29 -0500 (EST)

Reminder: only one week remains in these WGLCs.

I believe we have not seen any comments on 6112bis yet; please consider
commenting on it (and the other documents) if you have not already done
so.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 13 Feb 2015 13:16:51 -0500 (EST)

> I reviewed this and did not find any problems with it.

I also did not find any substantive issues with it.  Some non-substantive
issues are noted below.

The reference for the Kerberos V GSS-API mechanism in section 1.1 seems to
have changed from RFC 4121 to RFC 1964; is this a correct change?

The RFC 2119 language conventions statement has been moved later in the
document, after at least the first occurrence of "MUST".  It would be nice
to have the RFC 2119 text before the first use of its keywords.

The original RFC 4402 security considerations include:

   [...] if an
   application can be tricked into providing very large input octet
   strings and requesting very long output octet strings, then that may
   constitute a denial of service attack on the application; therefore,
   applications SHOULD place appropriate limits on the size of any input
   octet strings received from their peers without integrity protection.

It is not clear to me that integrity protection is sufficient to alleviate
the denial of service attack, since verifying the message integrity may
itself consume a substantial amount of resources.

In the added text,

% This document obsoletes RFC 4402 and reclassifies that document as
% historic.  RFC 4402 starts the PRF+ counter at 1, however a number
% implementations starts the counter at 0.  As a result, the original

it should be "a number of implementations start" (add "of" and remove 's'
from "starts") to be grammatical.

Thanks again to Greg for supplying the test vectors.

-Ben

---

From: Nico Williams <[email-masked]>
Date: Sun, 15 Feb 2015 20:00:36 -0600

FYI, these are useful links for reviewing these I-Ds:

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-kitten-rfc4402bis-00.txt
http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-kitten-rfc5653bis-02.txt&url1=rfc5653.txt
http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-kitten-rfc6112bis-00.txt

---

From: Nico Williams <[email-masked]>
Date: Sun, 15 Feb 2015 22:10:28 -0600

Please forgive me for being so late with these reviews.

> http://tools.ietf.org/html/draft-ietf-kitten-rfc4402bis-00

FWIW, my only comment as to rfc4402bis is that rfc4402 wasn't "my" RFC,
just an Internet RFC that I authored.  Not sure if that's even a nit.

> http://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-01

I've not reviewed the entirety of this document, just the docs from
RFC5653 to rfc5653bis-02.

Comments:

My one comment on the changes is that having GSSException()
constructors that take major and minor status code numbers seems...
like a bad idea, particularly as to minor status codes.  HOWEVER,
since some implementations may use an all-Java GSSException class even
with a JNI bindings for the rest of the API (or for specific mechanism
providers), it seems like a good idea for that purpose.  I don't think
this is worth mentioning in the I-D; this is really just a comment for
the mailing list archive.

> http://tools.ietf.org/html/draft-ietf-kitten-rfc6112bis-00

Ditto here, I'm only reviewing the changes, not the entire I-D.
Although I have one comment as to the original RFC:

 - Should we take this opportunity to define an AD to carry the PKINIT
   client cert and its validation cert chain (and trust anchor)?

Regarding the change in section 4.2, the only reason for not reducing
the MUST further to MAY is probably interoperability with TGSes that
implemented the "MUST return a KRB-ERROR..." text that is being deleted.
This seems to merit a mention, something like:

   If the ticket in the PA-TGS-REQ of the TGS request is an anonymous
   one, the client SHOULD set the anonymous KDC option in the request
   for interoperability with TGSes that insist on it.  The TGS SHOULD
   ignore the presence/absence of the anonymous KDC option in the
   request when the the ticket in the request is an anonymous ticket.

(Do we need to be more careful about defining "anonymous ticket"?

 Clearly this refers to tickets whose cname is anonymous, but in the
 user-to-user case the sname of the second ticket could be anonymous,
 and when we add post-dating, one could even have a TGS-REQ where the
 ticket has an anonymous sname.  Such a request is bound to fail, and
 makes no sense anyways!  This is just a twisted case just to
 demonstrate that it's the cname of a ticket that determines whether its
 an anonymous one or not.  Just a curiosity.)

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sun, 15 Feb 2015 22:21:08 -0600

On Fri, Feb 06, 2015 at 06:13:19PM -0500, Benjamin Kaduk wrote:
> [...]

Perhaps not, but a Java equivalent for GSS_Process_context_token would
be nice to have.

> [...]

I *think* what's happening here is that the streams in question are
synthetic ones containing *only* the GSS tokens.  Therefore there should
be no framing issue.  It's just a different way to represent a token.
The use of streams can be helpful in some applications, I'm sure, and
though an adaptor class would work just as well, these methods should
result in less application code.

That said, the use of streams strikes me as dangerous: in the presence
of a self-framing mechanism, an application that passes in streams
corresponding to the application protocol streams... would function
correctly, whereas it would fail to work with non-self-framing
mechanisms.

(The GSI mechanism that uses TLS is a self-framing mechanism.  When the
application writes the tokens without further framing the result is TLS
on the wire, even though a GSS interface is used!)

> error tokens under the application's control even when streams are used.

The above applies here as well.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sun, 15 Feb 2015 22:24:56 -0600

> on the wire, even though a GSS interface is used!)

That is, I am in favor of deprecating the methods dealing with streams,
or at the very least adding text describing the framing issue and
recommending (lower-case?) the use of memory-based, one-token-only
streams.

On the other hand, I do want to add a mechanism attribute for indicating
that a mechanism's tokens are self-framed...

Nico
--

---

From: Shawn M Emery <[email-masked]>
Date: Mon, 16 Feb 2015 21:13:24 -0700

Thanks for your review, comments in-line...

> have changed from RFC 4121 to RFC 1964; is this a correct change?

Good catch.  The XML source obtained referenced this back when it was a 
draft.  I've updated accordingly.

> to have the RFC 2119 text before the first use of its keywords.

Yes, this is awkward.  I've updated accordingly.

> itself consume a substantial amount of resources.

I interpret this statement differently:

     If integrity protection is not enforced then an attacker can 
construct an arbitrarily long string.

> Thanks again to Greg for supplying the test vectors.

...and also to Nico who verified the vectors in Heimdal.  Eventual 
shepherd should take note...

Shawn.
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 17 Feb 2015 16:41:55 -0500 (EST)

> http://tools.ietf.org/html/draft-ietf-kitten-rfc6112bis-00

I reviewed this one, and it seems fine.  A few minor (nonsubstantive)
issues below.

The new text says:

   In Section 7, pepper string 2 is corrected to comply with the string
 	   actually used by implementations.

However, the actual body text where the change to this string is made just
refers to it as "pepper2", so it might be better to be consistent and say
"the pepper2 string is corrected".

The introductory text in section 7 and the description of the attack read
almost as if they were originally written for a different context and just
dropped in place here; the terminology used does not match well with the
rest of the document.  For example, what are "channels"?  What does it
mean for a channel to have "a given name"?  The text here could probably
be drastically improved; perhaps we should take the time to do so since we
are already modifying the document.

I think that the attack could be expressed more cleanly, too -- "it is
desirable that neither the KDC nor the client unilaterally determine the
ticket session key" doesn't really say why.  What this extension is doing
is providing a binding between the party which generated the session key
and the DH exchange used to generate the reply key.  Supposing for the
sake of argument that the KDC picks the ticket session key as usual,
absent the use of PA-PKINIT-KX, the client and KDC would perform a DH key
exchange to determine a shared key, and that key would be used as the
reply key.  The KDC generates a ticket with session key as usual, and
encrypts the reply using the result of the DH agreement.  If there is a
MITM, the attacker can just decrypt the session key + ticket using the
DH key from the attacker<-->KDC DH exchange, and reencrypt it using the
key from the attacker<-->client DH exchange, keeping a copy of the session
key and ticket.  By requiring the session key to be a function of the
reply key in a way that can be verified by the client, this extension
binds the ticket to the DH exchange and prevents the MITM attack.

Some nits in the original RFC 6112 text:

In the introduction,

   [...] Note that
   the membership of a realm can imply a member of the community
   represented by the realm.

seems ungrammatical.

At the bottom of page 4, "For example, an anonymous principal that is
identifiable only within a particular group of users can be implemented
using authorization data and such authorization data, if included in the
anonymous ticket, would disclose the client's membership of that group."
is a bit awkward.  I would probably rephrase it as "For example, an
anonymous principal that is identifiable only as being one of a particular
group of users can be implemented using authorization data.  Such
authorization data, if included in the anonymous ticket, would disclose
that the client is a member of the group in question."

In section 4.1:

   The Kerberos client can use the client's long-term keys, the client's
   X.509 certificates [RFC4556], or any other pre-authentication data,
   to authenticate to the KDC and requests an anonymous ticket in an AS
   exchange where the client's identity is known to the KDC.

I think that the final 's' in "requests" is ungrammatical and should be
removed.

At the top of page 6, "According to [RFC4120]" could just as easily be "As
specified by [RFC4120]", since this is just repeating standard Kerberos
behavior.

Two paragraphs later, we could
s/AD-INITIAL-VERIFIED-CAS/AD_INITIAL_VERIFIED_CAS/ (twice), since the
ad-type assigned number uses the underscores and the ASN.1 type uses
hyphens.  (This also appears in section 4.2 on page 9.)

The final paragraph of section 4.1 starts with "The client can use the
client keys"; the phrase "client keys" does not appear anywhere else in
this document, or RFC 4120, or RFC 4556.  Perhaps the intent was "the
client's key" instead.

In the last sentence of page 7, I think that "Anonymity PKINIT" should be
"Anonymous PKINIT".

In section 4.2, there's a missing space in "the anonymous KDC optionSHOULD
be set in the request."

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 17 Feb 2015 21:43:48 -0500 (EST)

On Mon, 16 Feb 2015, Shawn M Emery wrote:

>     If integrity protection is not enforced then an attacker can construct an
> arbitrarily long string.

Woudln't the attacker be able to do that without needing a very large
input string, though?  I guess the claims it that each individual
pseudo-random() call is more expensive on a long input, so your
interpretation is still plausible.

-Ben

---

From: Nico Williams <[email-masked]>
Date: Tue, 17 Feb 2015 21:40:57 -0600

> interpretation is still plausible.

I think the original was about use of the PRF to bind something like,
say, a TLS handshake.  Now suppose you send such messages that are
very large prior to completing authentication.

Anyways, it's not a realistic problem.  I think that was stretching to
cover what in retrospect strikes me as a non-issue.

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 17 Feb 2015 22:45:05 -0500 (EST)

> the mailing list archive.

Yeah, it's a bit late to try to not have minor codes in the constructor
argument list.

>    client cert and its validation cert chain (and trust anchor)?

That seems more like something I would want to put in a 4556bis than a
6112bis (though of course there is no rule preventing it from being done).
I'm inclined to not try to add such an AD in at this time.

>    request when the the ticket in the request is an anonymous ticket.

I think we should say something about "for interoperability with ..."
("insist on it" is probably too colloquial).  I had pondered saying
something about the TGS behavior when I reviewed this change as well, but
did not say anything about it in my review.  I don't see any harm in
spelling it out, though.

> (Do we need to be more careful about defining "anonymous ticket"?

You mean here in 4.2?  I don't think so; section 3 has an extensive
definition of what it means to be an anonymous ticket.

>  an anonymous one or not.  Just a curiosity.)

Oh, but maybe we should be more careful about "in the request", hmm.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 20 Feb 2015 16:53:09 -0500 (EST)

> http://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-01
(an -02 witih editorial fixes was issued during the WGLC)
> http://tools.ietf.org/html/draft-ietf-kitten-rfc6112bis-00

Now that the WGLC period is over, I've gone through the on-list discussion
to determine the outcome of the WGLC.

Shawn has made some editorial fixes to rfc4402bis already; there are a few
more, but then I think we can put out an -01 and progress it forward.

There seems to be general agreement on the GSSException additions in
rfc5653bis, but further discussion is needed on the preexisting issue
raised about the stream-based methods.  It seems likely that the resulting
document update will be substantial enough to require another WGLC.

rfc6112bis received the fewest comments, which were mostly editorial but a
couple minor substantive issues were raised.  A new version should be
issued incorporating the suggested changes.  The minor substantive issues
may be minor enough that another WGLC is not needed, but it is not
entirely clear since the new text is not finalized yet.  Sam, you
submitted the -00 -- will you be able to submit the update as well?

Thanks,

Ben

---

From: Shawn M Emery <[email-masked]>
Date: Mon, 23 Feb 2015 11:19:08 -0700

> cover what in retrospect strikes me as a non-issue.

If this is the case then I think this problem is really outside the 
scope of the specification and in general applications would be 
susceptible to such DoS attacks.  I believe the consensus in the WG is 
that this sentence be elided from the bis draft.  I will make the 
necessary update if so.  BTW, I should probably move myself as an editor 
of the draft.

Shawn.
--