Subject: RE: Do we have any consensus on the 8003 checksum--text follows this line--

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Sun, 7 Sep 2003 10:57:15 -0700

Nicolas Williams wrote:

>>   -- [explicit tagging environment]
>>   REP-TOKEN ::= CHOICE {
>>      krb-error [0] KRB-ERROR,
>>      rep-token [1] SEQUENCE {
>>         body      [0] REP-TOKEN-BODY,
>>         mic       [1] OCTET STRING OPTIONAL -- a MIC of the body
>>      }
>>   }

Would KRB_ERROR end up with two TOK_IDs in this design?  Or do you want
to deprecate the separate TOK_ID for KRB_ERROR?

>> This could be useful even today.  For example, consider negotiation
of >> 
>> confidetiality ptoection: Sun used to ship a crippled version of the
>> rfc1964 mech that didn't support conf_flag for export purposes and a
>> domestic version that did - currently a non-crippled initiator asking
>> for confidentialilty protection from a crippled acceptor can only get
a
>> KRB-ERROR reply, as opposed to an AP-REP and an integrity protected
>>> indication that the server does not support confidentiality.

This information can be carried via the e-data typed hole in the
KRB_ERROR message, assuming it does not need to be MIC'ed.

>> The init token would have the same options typed hole added to the
end
>> of checksum 0x8003 data.

Would it be cleaner to encode the data for 0x8003 in ASN.1, and then add
the "options" typed hole?  Also I think you can make it OPTIONAL.

>>   REP-TOKEN-BODY ::= SEQUENCE {
>>      ap-rep     [0] AP-REP,
>>      status     [1] UInt32, -- major status

Can you have a non-successful major status code and an AP-REP token (not
KRB_ERROR) at the same time? 

I still think it is easier if we just insert an OPTIONAL typed hole into
the AP_REP, and leave the work for the extensions.  We can do the same
thing to checksum type 8003.  This way, we can move quickly with the AES
work.  

Thx.

Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Nicolas
Williams
Sent: Sunday, September 07, 2003 12:39 AM
To: Jeffrey Hutzelman; Sam Hartman; [email-masked]
Subject: Re: Do we have any consensus on the 8003 checksum--text follows
this line--

On Sat, Sep 06, 2003 at 01:57:46PM -0700, Nicolas Williams wrote:
> On Sat, Sep 06, 2003 at 12:58:57PM -0400, Jeffrey Hutzelman wrote:
> > >On Fri, Sep 05, 2003 at 04:46:02PM -0400, Sam Hartman wrote:
> > >So, for the reply token I propose:
> > >
> > >{oid, tok id, AP-REP, extra-data, MIC({AP-REP, extra-data})}
> > 
> > 
> > Just encode this as { oid, tok id, XXX }
> > where XXX is a sequence of { type, length, value } tuples, with a
type 
> > reserved for the AP-REP, and another for the MIC (which must be
last).  If 
> > other types are critical, then you probably should define an
IF-RELEVANT 
> > type, as we did with authorization data in kerberos-clarifications
(sec 
> > 5.2.6.1).
> 
> Sure, we know how to design this sort of thing (and note that this
being
> a context token use of ASN.1 would be fine, as nice alignments and
> performance aren't very relevant in this context).  I'd like to get
> consensus that this is the way to go.

Ok, now that I'm thinking about the structure details; one possible
design would be:

{ oid, tok_id, DER encoding of REP-TOKEN }

where REP-TOKEN is:

   -- [explicit tagging environment]
   REP-TOKEN ::= CHOICE {
      krb-error [0] KRB-ERROR,
      rep-token [1] SEQUENCE {
         body      [0] REP-TOKEN-BODY,
         mic       [1] OCTET STRING OPTIONAL -- a MIC of the body
      }
   }

   REP-TOKEN-BODY ::= SEQUENCE {
      ap-rep     [0] AP-REP,
      status     [1] UInt32, -- major status
      gss-flags  [2] GSS-FLAGS, -- a bit string, like gss flags in init
token
      options    [3] SEQUENCE OF SEQUENCE {
         option-type  [0] Int32,       -- mech option type
	 option-data  [1] OCTET STRING -- mech option
      }
   }

   -- UInt32 and Int32 are as in clarifications
   -- GSS-FLAGS is a BIT STRING with named bits
   -- ...

[The MICed data would include the AP-REP in spite of the fact that
 technically the MIC would be bound to the context anyways - this is
 because it would be easier to verify the connection if the AP-REP is
 included in the MICed data than if it isn't (if it isn't then the
 sequence number has to be verified, which breaks the GSS sequence
 number abstraction and so would complicate the implementation).]

The init token would have the same options typed hole added to the end
of checksum 0x8003 data.

This could be useful even today.  For example, consider negotiation of
confidetiality ptoection: Sun used to ship a crippled version of the
rfc1964 mech that didn't support conf_flag for export purposes and a
domestic version that did - currently a non-crippled initiator asking
for confidentialilty protection from a crippled acceptor can only get a
KRB-ERROR reply, as opposed to an AP-REP and an integrity protected
indication that the server does not support confidentiality.

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 7 Sep 2003 11:07:22 -0700

> to deprecate the separate TOK_ID for KRB_ERROR?

Bah, I forgot that KRB-ERROR had its own tok id.

> KRB_ERROR message, assuming it does not need to be MIC'ed.

It can't be MICed in the KRB-ERROR, at least not for now, and with
extensions KRB-ERROR integrity protection will depend on the sort of
error that took place.  See below.

> the "options" typed hole?  Also I think you can make it OPTIONAL.

I think so.  The options hole sequence could either be optional and
constrainted to have size 1.. or it could be mandatory but allow size 0.

> KRB_ERROR) at the same time? 

Not today, but if future extensions allow the acceptor to demand some
feature then the acceptor could return an AP-REP and the separate error
and the error could then be integrity protected.

> thing to checksum type 8003.  This way, we can move quickly with the AES

Optional with min size 1 or mandatory but allow size 0, either way.

Cheers,

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 08 Sep 2003 12:15:05 -0400

On Sunday, September 07, 2003 10:57:15 -0700 "Liqiang(Larry) Zhu" 
<[email-masked]> wrote:

> the AP_REP

Except that you can't do that, because it changes the message in a way that 
is not backward-compatible.  So you end up either specifying a new, 
backward-incompatible version of Kerberos or specifying a Kerberos GSS 
mechanism which does not use Kerberos messages.  Neither is desirable.

We will be working on adding typed holes to messages that are missing them 
as part of extensions.  In order to do this, we'll likely end up specifying 
new kinds of messages with new application tags, as well as a precise model 
for determining when to send new messages vs old ones.  This is necessary 
because there are existing deployed implementations of RFC1510 (and soon, 
perhaps, kerberos-clarifications) which will reject badly-formed messages.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA