Subject: RE: updated GSSAPI draft and summary of the off-list discussions

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 1 Sep 2003 23:16:40 -0700

Ken Raeburn wrote:
>> Section 1: Change "obsoletes" to "updates"; calling it obsolete and
>> then using it as a normative reference would be inconsistent.  Or, do
>> consider RFC 1964 obsolete, but incorporate all the relevant
>> specifications so that a session using a DES session key can be done
>> compatibly.

I would lean towards "updates" too.

>> Section 7.1: If we change anything in context initiation, we should
>> try to move away from this bogus conjured-up "checksum as arbitrary
>> octet string we can stuff data into" business.  In Clarifications
(and
>> probably RFC 1510, but I haven't double-checked), the checksum field
>> of an authenticator is a checksum of associated application data, and
>> what RFC 1964 stuffs in there is no checksum.  (If we had AEAD, etc,
>> etc.)

It is a misnomer but otherwise benign. Is there another way to carry the
GSS checksum flags, the channeling binding information, and the krb_cred
message?  Is it too late to create a "SEQUENCE OF SEQUENCE" type hole in
the authenticator?

>> Section 8.2: Is bit 0 the most significant bit in this field also?

Correct, this is now clarified in -02.

>> I don't think we actually get any benefit from having EC in the token
>> header of Wrap-with-confidentiality, do we?  The useful copy is in
the
>> encrypted data.

I agree. This was done more for simplicity than for security.

>> Section 8.3, last paragraph: Should be, "When AES is used, for
>> example", to make it crystal clear that the paragraph is
>> demonstrating, not specifying, how the values are calculated.

Fixed in -02

>> I'm not sure that including EC in the checksummed data for
>> Wrap-without-confidentiality gains us much either. 

EC is used as an attempt to separate plaintext data from checksum.
Since the EC filed does not need to be protected, to avoid "chicken-egg"
dilemma, we can fill EC with zeroes when we calculate the checksum.

>>  If the EC value is
>> supplied but not protected, and someone alters it such that the
>> checksum appears to be longer or shorter, the checksum verification
>> should fail.

That is right.  It is only needed when the checksum has variable sizes
in the crypto system being used. 

>> So we could consider placing EC at the end and not in the real token
>> header, inside the encrypted data but not in the checksummed data.

>> It *might* be useful if you are trying to do scatter-gather type i/o,
>> to put the different bits of data into different buffers, but it
would
>> require that you read EC from the token header before allocating
space
>> to put the rest of the token, which will have its own performance
>> implications.

I do not see this: for "native" SSPI applications, the buffers are sent
separately, non-native SSPI applications do not support s/g i/o.

>> Section 8.4: In the non-encrypted Wrap token, the MIC is computed
over
>> the plaintext data followed by the header.  This is done for
>> performance reasons when the supplied plaintext data is
block-aligned.
>> But for an implementation that constructs the data to checksum in one
>> buffer, the token buffer, it isn't the optimal approach.  It would be
>> better for such implementations if the MIC were computed over the
>> theader and then the plaintext data -- in exactly the form you'd
>> already have them laid out in the buffer.  I'm not sure if the
>> alignment makes much difference for most checksum type operations,
but
>> it seems to me we're optimizing for the scatter-gather implementation
>> by imposing an extra cost on the one-buffer implementation.

>> * The application must be able to compute the checksum size without
>>   knowing exactly what the data is.  (In private discussions, we went
>>   around and around on encryption output size and encryption
>>   functions incorporating compression and thus producing output
>>   varying in size based on the data itself, but we didn't get into
>>   checksums as much.)  The length is known in this case, as is most
>>   of the data except for the EC bytes.

>>   I don't think we currently require that checksums in general have
>>   fixed sizes.

The intention for putting the header at the end was mainly to make Wrap
tokens without confidentiality symmetric to those with confidentiality.

Having the header at the end has the added benefit of preventing
"message extension" attacks (that is an attacker can add additional data
to the end of a message without recalculating the checksum for the
existing message), which is not applicable to HMAC checksums in
simplified profiles.

We can say that the EC field is 0 when calculating the checksum.

Should we add the restriction to make checksum have fixed sizes? What
does the variable-size checksum buy us? In general, I would also prefer
to remove non-essential generality, which generally means simplicity.

>> I'd like to see diagrams of the data layout in 8.4.

These will be added into -02

>> There isn't a description of how the size of the random filler is
>> chosen.  I'd suggest something like this in place of the third
>> paragraph:

>>  In Wrap tokens that provide for confidentiality, the first 16 bytes
>>  of the Wrap tokens (the "header") are appended to the plaintext data
>>  before encryption.  In order for the recipient to be guaranteed to
>>  be able to locate this header in the decrypted token, the resulting
>>  message should be expanded to a size for which the [KCRYPTO]
 >>  encrypt/decrypt sequence will add no additional padding.  This
 >> expansion is done by inserting filler bytes into the constructed
 >> Wrap token after the plaintext application data and before the copy
 >>  of the token header.  The values in these bytes are unspecified.

 >> The resulting Wrap token is ....

>> ...and then don't describe the filler bytes as "random" in 8.3.  It
>> might add a very tiny amount of security to use a strong random
number
>> generator, but I don't think we lose a lot by using a constant zero
>> filler either, given that it'll tend to be less than a block anyways.

>> Do we really need to require that the size used is always the
smallest
>> suitable size?  Or can it just be *a* possibly-larger size, so long
as
>> It's less than 64K above the current size?  Strictly speaking, we
>> probably only need the latter, and the 64K bound is needed either
way.

It was suggested to allow EC for alignments.  There is indeed ambiguity
on how the filler bytes are chosen, and we did not give any guidelines
how to choose the filler bytes: the sender can choose any filler as long
as there is no crypto-system garbage after decrypt().  It should be
noted that for crypto-systems that do not generate crypto-garbage, the
filler can be non-empty.  

Also do we really want to say "padding" here?
 
>> Purely from a presentation point of view, it might be an easier read
>> if the proposed changes to [KCRYPTO] were described first, perhaps
>> indented and narrowed, or otherwise made to appear "special", and
then
>> the "normal" description of how the thus-modified kcrypto operations
>> are used in this mechanism.

This is now fixed in -02

>> Section 8.4, last paragraph: Say "for example", as I remarked for 8.3
above.

Fixed in -02

>> Section 8.5: So, RRC is treated as an unsigned value?  The rotation
>> can't go the other way?  (No, I don't have a good example at the
>> moment why you might want to do it that way.)  I don't remember if we
>> decided anything in our off-list discussions.

We need to handle messages less than 64k, the "net" RRC should be
interpreted as "RRC mod m", where m is the size of the encrypted data.
That is, for example, if the encrypted data size is 8, if you want to
right rotate -3 bytes, you can just right rotate 5 bytes. So it is
effective signed.

I think most people would have the impression that a reminder is always
non-negative and that is ok here.

>> Section 8.6: The "flags" byte has an extra blank line in the middle
of
>> its description in each message, as does the RRC description in the
>> Wrap token.

Fixed in -02

>> Section 9.1.2: "Principal in credential cache does not match desired
>> name" has assumptions about the implementation details.  How about
>> "Client principal in credentials does not match specified name"?
>> Likewise for some of the other messages....  "No key available for
>> specified service principal"; "No Kerberos ticket-granting ticket
>> available"; etc.

Sounds good. 

>> Can an implementation acting as initiator use a keytab for storing
the
>> client's long-term key?  If so, do you return KEYTAB_NOMATCH if the
>> client principal name doesn't match anything in the keytab?

MS does not return minor codes, can you double check to verify this?

>> Section 10: Probably could use some clarification.  Use some text
from
>> [3DES] if it helps.

>> Section 11: If this is to go on the standards track, it shouldn't
>> refer to the draft for 3DES that I allowed to expire.  Copy the text
>> you need.

Will do.

Thanks. 

Larry

-----Original Message-----
From: Ken Raeburn [mailto:[email-masked]] 
Sent: Monday, September 01, 2003 7:04 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]
Subject: Re: updated GSSAPI draft and summary of the off-list
discussions

This is kind of long, but much of it is nit-picky stuff.  We're
definitely getting closer....

Section 1: Change "obsoletes" to "updates"; calling it obsolete and
then using it as a normative reference would be inconsistent.  Or, do
consider RFC 1964 obsolete, but incorporate all the relevant
specifications so that a session using a DES session key can be done
compatibly.

Section 7.1: If we change anything in context initiation, we should
try to move away from this bogus conjured-up "checksum as arbitrary
octet string we can stuff data into" business.  In Clarifications (and
probably RFC 1510, but I haven't double-checked), the checksum field
of an authenticator is a checksum of associated application data, and
what RFC 1964 stuffs in there is no checksum.  (If we had AEAD, etc,
etc.)

Section 8.2: Is bit 0 the most significant bit in this field also?

Section 8.3, last paragraph: Should be, "When AES is used, for
example", to make it crystal clear that the paragraph is
demonstrating, not specifying, how the values are calculated.

I don't think we actually get any benefit from having EC in the token
header of Wrap-with-confidentiality, do we?  The useful copy is in the
encrypted data.

I'm not sure that including EC in the checksummed data for
Wrap-without-confidentiality gains us much either.  If the EC value is
supplied but not protected, and someone alters it such that the
checksum appears to be longer or shorter, the checksum verification
should fail.

So we could consider placing EC at the end and not in the real token
header, inside the encrypted data but not in the checksummed data.

It *might* be useful if you are trying to do scatter-gather type i/o,
to put the different bits of data into different buffers, but it would
require that you read EC from the token header before allocating space
to put the rest of the token, which will have its own performance
implications.

Section 8.4: In the non-encrypted Wrap token, the MIC is computed over
the plaintext data followed by the header.  This is done for
performance reasons when the supplied plaintext data is block-aligned.
But for an implementation that constructs the data to checksum in one
buffer, the token buffer, it isn't the optimal approach.  It would be
better for such implementations if the MIC were computed over the
theader and then the plaintext data -- in exactly the form you'd
already have them laid out in the buffer.  I'm not sure if the
alignment makes much difference for most checksum type operations, but
it seems to me we're optimizing for the scatter-gather implementation
by imposing an extra cost on the one-buffer implementation.

I'd like to see diagrams of the data layout in 8.4.

The use of EC for the size of the checksum in Wrap tokens without
confidentiality imposes other limits on kcrypto not covered in 8.4:

 * No checksum algorithm may ever produce an output greater than 65535
   bytes.

 * The application must be able to compute the checksum size without
   knowing exactly what the data is.  (In private discussions, we went
   around and around on encryption output size and encryption
   functions incorporating compression and thus producing output
   varying in size based on the data itself, but we didn't get into
   checksums as much.)  The length is known in this case, as is most
   of the data except for the EC bytes.

   I don't think we currently require that checksums in general have
   fixed sizes.

There isn't a description of how the size of the random filler is
chosen.  I'd suggest something like this in place of the third
paragraph:

  In Wrap tokens that provide for confidentiality, the first 16 bytes
  of the Wrap tokens (the "header") are appended to the plaintext data
  before encryption.  In order for the recipient to be guaranteed to
  be able to locate this header in the decrypted token, the resulting
  message should be expanded to a size for which the [KCRYPTO]
  encrypt/decrypt sequence will add no additional padding.  This
  expansion is done by inserting filler bytes into the constructed
  Wrap token after the plaintext application data and before the copy
  of the token header.  The values in these bytes are unspecified.

  The resulting Wrap token is ....

...and then don't describe the filler bytes as "random" in 8.3.  It
might add a very tiny amount of security to use a strong random number
generator, but I don't think we lose a lot by using a constant zero
filler either, given that it'll tend to be less than a block anyways.

Do we really need to require that the size used is always the smallest
suitable size?  Or can it just be *a* possibly-larger size, so long as
it's less than 64K above the current size?  Strictly speaking, we
probably only need the latter, and the 64K bound is needed either way.

Purely from a presentation point of view, it might be an easier read
if the proposed changes to [KCRYPTO] were described first, perhaps
indented and narrowed, or otherwise made to appear "special", and then
the "normal" description of how the thus-modified kcrypto operations
are used in this mechanism.

Section 8.4, last paragraph: Say "for example", as I remarked for 8.3
above.

Section 8.5: So, RRC is treated as an unsigned value?  The rotation
can't go the other way?  (No, I don't have a good example at the
moment why you might want to do it that way.)  I don't remember if we
decided anything in our off-list discussions.

Section 8.6: The "flags" byte has an extra blank line in the middle of
its description in each message, as does the RRC description in the
Wrap token.

Section 9.1.2: "Principal in credential cache does not match desired
name" has assumptions about the implementation details.  How about
"Client principal in credentials does not match specified name"?
Likewise for some of the other messages....  "No key available for
specified service principal"; "No Kerberos ticket-granting ticket
available"; etc.

Can an implementation acting as initiator use a keytab for storing the
client's long-term key?  If so, do you return KEYTAB_NOMATCH if the
client principal name doesn't match anything in the keytab?

Section 10: Probably could use some clarification.  Use some text from
[3DES] if it helps.

Section 11: If this is to go on the standards track, it shouldn't
refer to the draft for 3DES that I allowed to expire.  Copy the text
you need.

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 2 Sep 2003 08:10:22 -0700

> message?  Is it too late to create a "SEQUENCE OF SEQUENCE" type hole in

In extensions we can, should, and, I think will add a typed hole to the
authenticator.  I was willing to define KRB-SAFE-X in the mech I-D
rather than wait for extensions, but I'm not willing to defined
Authenticator-X in the mech I-D rather than in extensions.

The difference lies in the difference in utility and importance of the
two types.  We really have to get the new authenticator and AP-REP, the
whole AP exchange, really, right.

Also, if we're going to support any kind of negotiation in the mech then
we'll need a typed hole in the AP-REP enc part (see above).

If we really want to do this now we have two choices: a) build new
context tokens based on AP messages and wraps bound to those messages,
b) extend the AP messages/types now.

> dilemma, we can fill EC with zeroes when we calculate the checksum.

Do we need nice alignments in the checksum operation?  I don't think so.

> tokens without confidentiality symmetric to those with confidentiality.

I don't think that's worth the trouble for one-buffer implementations.

> to remove non-essential generality, which generally means simplicity.

I'd rather say that enctypes w/ variable size checksums need to be
cryptographically secure against "message extension" attacks.

> MS does not return minor codes, can you double check to verify this?

The same set of minor status codes should be used for errors relating to
initiator credentials regardless of how those credentials are initially
acquired (keytab, interactive prompting, smartcards, ... - doesn't
matter where the keys live, as long as we can consider them initiator
creds that's what they are [much the same applies to acceptor
credentials]).

Cheers,

Nico
--

---

From: "Joel N. Weber II" <[email-masked]>
Date: Tue, 02 Sep 2003 13:44:45 -0400

[I'm mostly not following this discussion, because I've been busy with
other things.]

> authenticator.

I'm pretty sure there's already an authorization-data field there that
can serve as a typed hole.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 2 Sep 2003 11:43:49 -0700

> can serve as a typed hole.

The GSS context flags, channel bindings, delegated credential and many
future GSS-APIv3 options that I can think of don't qualify as authz-
data[*].  To use the authz-data of the authenticator for what currently
goes in the checksum 0x8003 data would merely replace one semantic hack
with another.  I am not enthused.

As for Kerberos V extensions, we need a generic typed hole in the AP-REP
encpart, so we might as well add a generic typed hole in the
Authenticator, thus avoiding overloading the semantics of the authz-data
hole.

[*]  Well, you can think of channel bindings as authorization data
     ("only if we have the same channel"), but channel bindings actually
     qualify as data whose checksum ought be sent in the checksum field
     of the Authenticator (and why isn't that checksum field a SEQUENCE
     OF anyways?).

Cheers,

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 02 Sep 2003 17:01:15 -0400

"Liqiang\(Larry\) Zhu" <[email-masked]> writes:
> message?

From the description of the authenticator "cksum" field:

      This field contains a checksum of the application data that
      accompanies the KRB_AP_REQ, computed using a key usage value of 10
      in normal application exchanges, or 6 when used in the TGS-REQ PA-
      TGS-REQ AP-DATA field.

So, just send { AP_REQ, chan_bindings } and for the authenticator
checksum in AP_REQ, use the checksum of chan_bindings.

> dilemma, we can fill EC with zeroes when we calculate the checksum.

That would work, yes.

> existing message), which is not applicable to HMAC checksums in

Under what circumstances can these message extension attacks be
performed?  Should we be worried about any of our existing
cryptosystems being unsuitable for general use?

> to remove non-essential generality, which generally means simplicity.

What's essential and what's not?  Until the RC4 implementation came
along, I probably wouldn't have bothered with non-block-cipher
support.  I don't want to constrain things too much through
short-sightedness.  But at the same time, too many options do require
that the application protocol be able to handle them.

I'm not convinced these extra constraints are all needed.  Seems like
a lot of hoops to jump through to avoid incorporating an 8-byte (or
one-block) length field at the front of the application data.

> how to choose the filler bytes:

Not quite true -- throughout sections 8.3 and 8.4 you said "random
filler"; in this context, "random" doesn't mean "whatever you feel
like using", it implies the use of a random number source; whether a
weak PRNG would be acceptable or if a strong source is required might
be less clear.  That's why I explicitly used "unspecified".

> Also do we really want to say "padding" here?

I think "filler" is better, "padding" could be ambiguous, describing
the filler inserted by the mechanism and the trailing junk added by
the cryptosystem.

> non-negative and that is ok here.

I was thinking of messages much larger than 64K.  If you have a 300K
message, then under the current spec, you can move up to 64K from the
end to the beginning, but you can't move a small amount, say 256
bytes, from the beginning to the end.  (Like I said, I'm not sure if
we'd ever want to, just as I'm not sure we'd ever want to move more
than 32K from end to beginning.)

Though you do bring up an interesting point.  If the message size is
1K, can RRC be 2K, so that implementations may actually have to do the
modular math?  Or should we require that RRC be smaller than the
message size (or 0 for an empty message)?

> MS does not return minor codes, can you double check to verify this?

It wasn't an implementation question.  Should we return KEYTAB_NOMATCH
for anything keytab related, or should the messages instead be
oriented towards client credentials (usually credentials in a ccache,
maybe acquired via a long-term key stored in a keytab, whatever)
versus server credentials (stored in keytab, or ccache for
user-to-user, whatever)?  I think it should be the latter, and
mentions of keytabs and ccaches should not be in the generic error
messages, though perhaps an implementation may wish to use such terms.

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 2 Sep 2003 14:48:24 -0700

> checksum in AP_REQ, use the checksum of chan_bindings.

Quite reasonable.  And not just the channel bindings either, but the
GSS flags, the optional KRB-CRED, and any extensions.

The reply token format could be {AP-REQ, GSS_Wrap(gss reply data)} where
<gss reply data> would be empty for GSS-APIv2 uses but possibly
non-empty for future v3 uses.

[...]
> one-block) length field at the front of the application data.

Are you referring only to Larry's proposed constraint that checksums be
fixed-sized?  Or are you referring to the other constraints we've
already agreed on?

If the latter, I suppose it would be useful to have some information
about the length distribution of wrapped data in real-life uses of the
GSS-API.  NFSv2/3/4, FTP and DCE RPC are some commonly used protocols
where performance matters and which use or can use the GSS-API.

[...]
> than 32K from end to beginning.)

IIRC, from the off-list discussion, MS will fix the SSPI to make usage
of the RRC go away, so even though the RRC field is too small to support
use of the current SSPI with general kcrypto enctypes, it's just fine
for now.

Cheers,

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 02 Sep 2003 21:35:34 -0400

> GSS flags, the optional KRB-CRED, and any extensions.

Um, yeah.  The whole thing.  Actually, the channel bindings are known
to both sides, just the MD5 hash is used, so the hash would presumably
be used again in this case.  (Yet another plug for AEAD.)

> non-empty for future v3 uses.

The reply token should be using AP-REP, shouldn't it?  There's no
place there for an additional checksum.  So we'd need a checksum for
the reply data.

> fixed-sized?  Or are you referring to the other constraints we've

Well, in general, most of them aren't needed, but we have agreed on
some for purposes of optimization and SSPI compatibility, haven't we? :-)
But now, I think we're adding more, and I don't think we discussed
them.  And we haven't said, "oh, whatever, go ahead and add whatever
constraints you want".  So, new constraint, more discussion.

> where performance matters and which use or can use the GSS-API.

That would be useful anyways.  In fact, I was going to send a note to
krbdev on a related matter, key scenarios for measuring the MIT
implementation performance.

> use of the current SSPI with general kcrypto enctypes, it's just fine

Yes, 0..32767 is more than we're likely to need; for that matter, I
hope that 0..127 is more than enough.  I just want the interpretation
of the other 2**15 values to be thought about, not written up some
random way because no one bothered to think about it.

Ken

---

From: "Joel N. Weber II" <[email-masked]>
Date: Wed, 03 Sep 2003 00:42:30 -0400

> cryptosystems being unsuitable for general use?

``Section 6.3.1 Length Extensions'' of Schneier + Ferguson's Practical
Cryptography describes the attacks.  Basically, the problem is that,
with the way md5 and sha1 are defined, if you know the hash for a
block of data, you can take that hash plus data you want to add to the
end of the block of data and calculate a hash for the new whole.  This
is particularily interesting if some of the data hashed in the initial
block of data is data Eve doesn't know, such as a key being used for
integrity checking.

(Those hash functions do add the length and some filler after the
data, so I believe doing this attack would require that the
application data happen to tolerate that length and filler data being
there.)

That book doesn't go into a detailed analysis of exactly when you can
get away with not worrying about this, because it takes a very
conservative attitude.  They do recommend using HMAC to avoid this
problem.

I suspect if the data you feed into the integrity function includes a
length in a fixed location near the beginning of the data being fed to
the hash function, that is sufficient to prevent these attacks, even
if you don't use hmac.  So I think we can either make sure that gssapi
and krb-safe and krb-priv use a length value in that fashion, or else
make sure that the kcrypto framework has requirements language that
requires the integrity check to somehow protect against message
extension attacks.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Sep 2003 18:34:39 -0400

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

    Nicolas> On Tue, Sep 02, 2003 at 01:44:45PM -0400, Joel N. Weber
    Nicolas> II wrote:
    >> [I'm mostly not following this discussion, because I've been
    >> busy with other things.]
    >> 
    >> > In extensions we can, should, and, I think will add a typed
    >> hole to the > authenticator.
    >> 
    >> I'm pretty sure there's already an authorization-data field
    >> there that can serve as a typed hole.

    Nicolas> The GSS context flags, channel bindings, delegated
    Nicolas> credential and many future GSS-APIv3 options that I can
    Nicolas> think of don't qualify as authz- data[*].  To use the
    Nicolas> authz-data of the authenticator for what currently goes
    Nicolas> in the checksum 0x8003 data would merely replace one
    Nicolas> semantic hack with another.  I am not enthused.

We seem to have reached a previous consensus that we are expanding
padata and authorization data to be generic typed holes in the places
where they appear.

---

From: Ken Raeburn <[email-masked]>
Date: Wed, 03 Sep 2003 17:34:41 -0400

"Joel N. Weber II" <[email-masked]> writes:
> end of the block of data and calculate a hash for the new whole.

Oh, for a simple known hash, yes.  That's why you need some final step
the attacker can't reverse, like an additional hash (HMAC) or
encryption (rsa-md5-des etc).

If any of our checksum algorithms were vulnerable to this, they would
be nearly useless.  (The up-front length in the DER encoding would
still give some protection to checksums of ASN.1 data.)

> if you don't use hmac.

Probably, since changing the length would change the hash of the
previous data, making it no longer just an extension.

>   So I think we can either make sure that gssapi

Perhaps.

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 3 Sep 2003 15:41:52 -0700

> padata and authorization data to be generic typed holes in the places

Really?  It's been a while, so if we did my memory fails me - I'm sure
we'll discuss this at the interim meeting.  We still need a typed hole
in the AP-REP encpart though.

I realize, of course, that we'll be overloading padata for the purpose
of negotiating the use of extensions with the KDC, but that seems rather
fundamentally necessary.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 03 Sep 2003 18:55:23 -0400

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

    Nicolas> Really?  It's been a while, so if we did my memory fails
    Nicolas> me - I'm sure we'll discuss this at the interim meeting.
    Nicolas> We still need a typed hole in the AP-REP encpart though.

    Nicolas> I realize, of course, that we'll be overloading padata
    Nicolas> for the purpose of negotiating the use of extensions with
    Nicolas> the KDC, but that seems rather fundamentally necessary.

    Nicolas> Nico --

Actually, looking back at this, I think it was more like we reached
the consensus that we had typed holes in those messages already, and
that we needed at least one typed hole.  In all the encoding
proposals, no additional typed holes were added when already present,
but I don't thin anyone explicitly asked the question of whether this
is appropriate.

I had always assumed it was because everyone agreed that expanding the
existing holes was sufficient.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 3 Sep 2003 16:00:47 -0700

> existing holes was sufficient.

For extensions I'm quite happy with expanding the semantics of existing
typed holes (though I doubt we'll change their names).  See below.

I suppose that should mean use of new types that conform to the new hole
semantics in extensions should be allowed in rfc150/clarifications
contexts where that is actually feasible.

I'll have to think about this some more.  Some new types for these holes
may have uses in several kinds of holes, so we may either need multiple
type selector assignments or a unified bit of namespace for generic
typed hole uses.

Nico
--