[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TGS revisited

From: Simon Josefsson
Subject: Re: TGS revisited
Date: Wed, 26 Apr 2006 15:52:22 +0200
User-agent: Gnus/5.110005 (No Gnus v0.5) Emacs/22.0.50 (gnu/linux)

Elrond <address@hidden> writes:

>> The seq-number shouldn't cause problems, but we could try removing it,
>> it really shouldn't be there.
> So according to the specs, those parts should not be there?

For the subkey 3.3 is pretty clear that TGS can use them, but heimdal
gets this wrong (it encrypts the response using the ticket key

For seq-number, there isn't a normative statement when it MUST NOT be
used in TGS, but it is suggested that it is only useful for KRB_PRIV

      This optional field includes the initial sequence number to be
      used by the KRB_PRIV or KRB_SAFE messages when sequence numbers
      are used to detect replays.  (It may also be used by application

However, in theory, I think seq-number could be useful in TGS, to
prevent replays, OTOH since it is so small, it isn't all that useful.

>> >    a) If I find the time, I will compile it on another box
>> >       with access to the w2k3-kdc.
>> >    b) Do I have a realistic chance to verify checksums by
>> >       "hand"? Setting it to md5 in crypto-rc4 would be my
>> >       first step, so that I would "only" need to run md5 on
>> >       some parts of the packet.
>> Shouldn't be too hard, the checksum is computed over the DER encoding
>> of the req-body in the KDC-REQ.
> So that should be just md5 of the rest of the packet after
> the authenticator?
> And it should be all unencrypted, of what I need to take
> the md5? That's nice, cause it should be simple to do with
> any packet capturing tool.


   In the case of requests for additional tickets (KRB_TGS_REQ),
   padata-value will contain an encoded AP-REQ.  The checksum in the
   authenticator (which MUST be collision-proof) is to be computed over
   the KDC-REQ-BODY encoding.

>> There is a XXX nit in
>> shishi_ap_set_tktoptionsasn1usage() which you could watch out for.
> That memmove looks interesting there...
> Is that to skip the asn1-tag and length?
> What if the encoded length is more than 128byte?
> (I'm just talking useless crap. You're fully free to ignore
> the last few lines. ;) )

I'm not sure what it is for, but it works so I haven't touched it. :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]