Subject: generic token framing in gssapi-cfx-02

From: Martin Rex <[email-masked]>
Date: Tue, 7 Oct 2003 15:10:11 +0200 (MET DST)

I just noticed that from gssapi-cfx-01 to gssapi-cfx-02 the
generic token framing of rfc-1964 was dropped on all but the
initial context token.  Did I miss the discussion of this change?

I think the generic gssapi token framing should be retained
on all context-level tokens which had this framing in rfc-1964.

Dropping that framing on the protected message tokens (wrap and mic tokens)
would save a little network bandwidth, however it does add significant
implementation complexity, i.e. using that framing must be supported
for rfc-1964 interoperability and also for prot-ready on a
rfc-1964bis connections where the initiator cannot yet know whether
the acceptor is rfc-1964 or rfc-1964bis.

When doing the change on the protected messages, then I hope that
implementors will perform serious interoperability testing on this
*BEFORE* shipping any code!

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Tue, 07 Oct 2003 11:08:28 -0400

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> I just noticed that from gssapi-cfx-01 to gssapi-cfx-02
    Martin> the generic token framing of rfc-1964 was dropped on all
    Martin> but the initial context token.  Did I miss the discussion
    Martin> of this change?

No, oops we should have called it out on the list.  The draft authors
and current implementers of the spec seem to believe it is a good
idea.

    Martin> I think the generic gssapi token framing should be
    Martin> retained on all context-level tokens which had this
    Martin> framing in rfc-1964.

    Martin> Dropping that framing on the protected message tokens
    Martin> (wrap and mic tokens) would save a little network
    Martin> bandwidth, however it does add significant implementation
    Martin> complexity, i.e. using that framing must be supported for
    Martin> rfc-1964 interoperability 

As one implementer, we're taking this opportunity to clean up our
GSSAPI code by having a different code path for the new token formats
than for the old token formats.  I believe that both Heimdal and
Microsoft are OK with any implementation complexities.  So it sounds
like a wide section of the implementers don't mind any complexity this
introduces for their implementation.

The reason we proposed removing the generic token framing was not
network size, but was rather that it made the header size
non-constant.

    Martin> and also for prot-ready on a
    Martin> rfc-1964bis connections where the initiator cannot yet
    Martin> know whether the acceptor is rfc-1964 or rfc-1964bis.

As written, the draft requires you know which token format you are
using before you send the first token.  Microsoft intends to have
non-standard support for using new token formats with old enctypes,
but they are doing this in a way that we as the IETF would be unlikely
to standardize.  I think both the token ID changes and this header
change require that they not support prot_ready in that negotiation
mode.

    Martin> When doing the change on the protected messages, then I
    Martin> hope that implementors will perform serious
    Martin> interoperability testing on this *BEFORE* shipping any
    Martin> code!

I hope so too.  I believe Microsoft and Heimdal are already close to
successful interoperability testing on this spec; MIT is a bit behind,
but we would be shocked if we have not tested interoperability before
IETF last call.

Is your only concern implementation complexity?  If so, I think it is
reasonable to drop that concern if we can demonstrate adequate testing
and adequate buy-in from the implementation community.

---

From: Martin Rex <[email-masked]>
Date: Tue, 7 Oct 2003 18:49:14 +0200 (MET DST)

> and current implementers of the spec seem to believe it is a good

In case there is extra code between the actual mechanism implementation
and a real GSS-API v2 conforming API (either a wrapper like my gsskrb5.dll
on top of Microsoft's SSPI or a third-party multi-mechanism wrapper or
third-party SPNEGO it is very helpful to have the generic GSS-API
framing on all context level tokens.

> introduces for their implementation.

Creating two seperate code pathes is not what *I* consider clean;
it increased code complexity and maintenance.  For backwards
compatibility you must retain the existing code path (because of
reusing the rfc-1964 mechanism OID).

To me that sounds more like creating yet another TextEditor because
none of the existing fits one's taste.

Absent clear technical benefits the correct engineering decision is
to leave it as it is, even if it is not the best solution in
everyone's perception.

> network size, but was rather that it made the header size

In Microsoft's SSPI the "token header" on protected messages has
been implemented as a seperate "trailer", leaving the correct reassembly
into a single buffer for a GSS-API-compliant API to wrapping code
like my gsskrb5.dll.  I don't know whether Microsoft does that
reassembly in any of their native protocols or whether they simply
ignore that trailer -- my assumption was that they ignore it already.

> and adequate buy-in from the implementation community.

My concern is interoperability problems, and Microsoft doesn't
have a very good track record concering interoperability when
it comes to software updates...

I'm currently faced with an interoperability problem which
Microsoft seems to have silently shipped with W2K3.  I don't know
what it is, but I have a hunch that it might be user2user.
And it looks like they're using a mech OID from MIT's nametype oid-space!?

The mechanism selection in SSPI is by name rather than by OID as in
GSS-API.  Although I did select "Kerberos", I seem to end up with
a different mechanism (OID) in W2K3 -- OUCH!
Unfortunately this strange change in behaviour completely break
interoperability with my existing gsskrb5.dll wrapper and
regular rfc1964-Kerberos.

RFC 1964 Kerberos 5 gssapi mechanism OID:
      {  9, (void *)"\x2a\x86\x48\x86\xf7\x12\x01\x02\x02"      },

Nametypes supported by MIT Kerberos:
      { 10, (void *)"\x2a\x86\x48\x86\xf7\x12\x01\x02\x02\x01"  }, /* MIT: Kerbe
ros 5 principal name (rfc1964) */
      { 10, (void *)"\x2a\x86\x48\x86\xf7\x12\x01\x02\x02\x02"  }, /* MIT: Kerbe
ros 5 principal name special internal format (???) */

OID in W2K3 security this context establishment:
      { 10, (void *)"\x2a\x86\x48\x86\xf7\x12\x01\x02\x02\x03"  }

The following is a full (and long, sorry) Hex-Dump of a W2K3 Kerberos
security context establishment, process-local with target and
initiator = Administrator.

>> sspit2k -p Kerberos -m -c -v
------------------------------------------------------------------------------------------------
Authenticating with/for Client User "[email-masked]"
InitializeSecurityContext Token  { &buf= 001470B8, len= 74 }
  000000  60 48 06 0a 2a 86 48 86  f7 12 01 02 02 03 04 00   `H..*.H. ........
  000010  30 38 a0 03 02 01 05 a1  03 02 01 10 a2 1a 30 18   08...... ......0.
  000020  a0 03 02 01 01 a1 11 30  0f 1b 0d 61 64 6d 69 6e   .......0 ,..admin
  000030  69 73 74 72 61 74 6f 72  a3 10 1b 0e 43 45 52 54   istrator ....CERT
  000040  2e 4d 53 41 44 53 2e 43  4f 4d                     .MSADS.C OM      
Name from Server Credentials "[email-masked]"
AcceptSecurityContext Token  { &buf= 00149FA0, len= 1006 }
  000000  60 82 03 ea 06 0a 2a 86  48 86 f7 12 01 02 02 03   `.....*. H.......
  000010  04 01 30 82 03 d8 a0 03  02 01 05 a1 03 02 01 11   ..0..... ........
  000020  a2 82 03 ca 61 82 03 c6  30 82 03 c2 a0 03 02 01   ....a... 0.......
  000030  05 a1 10 1b 0e 43 45 52  54 2e 4d 53 41 44 53 2e   .....CER T.MSADS.
  000040  43 4f 4d a2 23 30 21 a0  03 02 01 02 a1 1a 30 18   COM.#0!. ......0.
  000050  1b 06 6b 72 62 74 67 74  1b 0e 43 45 52 54 2e 4d   ..krbtgt ..CERT.M
  000060  53 41 44 53 2e 43 4f 4d  a3 82 03 82 30 82 03 7e   SADS.COM ....0..~
  000070  a0 03 02 01 17 a1 03 02  01 02 a2 82 03 70 04 82   ........ .....p..
  000080  03 6c ac 65 c4 0d 50 dd  b1 ad e0 78 8a 0c 4c 64   .l.e..P. ...x..Ld
  000090  79 77 93 f4 42 45 16 95  e6 20 98 81 0d cf 6f 2c   yw..BE.. . ....o,
  0000a0  d9 48 40 ec 8a 18 3f c1  0c 22 b9 eb 98 c3 e7 66   .H@...?. .".....f
  0000b0  43 49 76 53 96 93 c4 57  3a 2d 2d f1 69 22 0c 84   CIvS...W :--.i"..
  0000c0  07 95 7d 0b e4 09 67 f0  13 d6 6d 39 fd 1e da 18   ..}...g. ..m9....
  0000d0  43 11 79 19 56 c7 7d 5a  71 08 49 1a 1a 26 f9 be   C.y.V.}Z q.I..&..
  0000e0  97 d8 b1 f5 b8 f4 0d a9  d0 d3 b7 7c 33 35 62 98   ........ ...|35b.
  0000f0  4d ff 4a b4 64 cc 25 d6  55 4e 11 62 f0 f5 09 5f   M.J.d.%. UN.b..._
  000100  fc b8 ac 60 a8 09 ec cd  08 3d 4f fe 54 e2 3e 45   ...`.... .=O.T.>E
  000110  57 2c 96 96 6e b4 fa bf  fd 57 09 f0 21 df 90 3f   W,..n... .W..!..?
  000120  d5 01 8d d9 25 3c 37 8f  99 61 55 48 4f 71 52 7a   ....%<7. .aUHOqRz
  000130  e0 67 54 cf be ab 21 c5  a6 d3 b9 69 07 be 4d aa   .gT...!. ...i..M.
  000140  0e 4f d5 e1 23 c8 e2 f2  ca 7c 97 7f d5 73 ef 1a   .O..#... .|...s..
  000150  61 d8 a5 82 cd 96 95 f8  fc 7b a4 a8 3e 89 94 8c   a....... .{..>...
  000160  a5 52 93 17 d8 36 96 ed  11 62 3b c4 0a f2 65 54   .R...6.. .b;...eT
  000170  e3 9c 80 0a a7 9f 87 ce  a5 a5 1d cd 74 bc b8 1b   ........ ....t...
  000180  06 85 78 1b aa e5 c2 8e  09 2a 32 31 0a 98 8a 90   ..x..... .*21....
  000190  41 9c 74 90 ec d4 a8 82  ea 4b 3d 41 9a a8 11 70   A.t..... .K=A...p
  0001a0  3e e5 ad 01 8f 63 21 84  cd 90 4d c1 b3 a7 e0 70   >....c!. ..M....p
  0001b0  02 e9 9b 58 83 9d 34 3b  d5 99 46 6b 2d e2 11 72   ...X..4; ..Fk-..r
  0001c0  ac ab 05 cb cc bf b8 f0  e4 3a 27 a5 b8 f1 51 80   ........ .:'...Q.
  0001d0  6d 5c 83 69 7e d7 18 4c  99 42 00 a9 20 e9 92 34   m\.i~..L .B.. ..4
  0001e0  0f d2 06 84 17 5a 1c 51  ff 63 40 68 dd bf 56 d3   ,....Z.Q .c@h..V.
  0001f0  e7 4a f9 58 16 2b 2a af  3e 44 dd ae 3f 51 a2 62   .J.X.+*. >D..?Q.b
  000200  4f 1a fe a3 95 61 c2 79  fa 09 19 39 94 57 b7 40   O....a.y ...9.W.@
  000210  28 57 26 21 79 af 82 7c  79 2c 56 9f 99 4d 14 ca   (W&!y..| y,V..M..
  000220  6e d2 f6 b7 ff f4 b6 34  05 24 48 f6 bc 2b f6 ec   n......4 .$H..+..
  000230  b5 3a 27 5f d3 34 00 0d  81 99 76 20 1f 98 4a 33   .:'_.4.. ..v ..J3
  000240  02 99 12 f4 29 73 5c b1  da a7 99 fc c5 63 9f c4   ....)s\. .....c..
  000250  cb 89 c5 48 81 5d 71 ae  35 58 b9 e1 2e 2d ec e1   ...H.]q. 5X...-..
  000260  75 66 5b cb 8b d8 b2 1b  a4 00 cd 77 8e 47 90 b8   uf[..... ...w.G..
  000270  9e ff 45 0f e4 2f 4f 8c  85 1e 2e d9 ba 95 60 85   ..E,./O. ......`.
  000280  da 22 42 a3 ac 53 f9 d9  91 d9 aa 3d 74 78 ed 60   ."B..S.. ...=tx.`
  000290  60 fb 36 45 28 f3 26 6b  31 65 26 7c bb e8 38 8f   `.6E(.&k 1e&|..8.
  0002a0  4a 91 7c 48 69 2c c4 2c  44 a9 b3 af 53 d6 50 61   J.|Hi,., D...S.Pa
  0002b0  c2 21 6d bd 16 72 11 23  15 72 6b d8 9b 45 bd 4c   .!m..r.# .rk..E.L
  0002c0  5e 45 93 32 10 c0 99 92  ce cb 16 5d 49 6b 3a 40   ^E.2.... ...]Ik:@
  0002d0  73 48 06 dc 3c 61 cd 83  65 59 8b 23 99 e2 c8 7a   sH..<a.. eY.#...z
  0002e0  b3 c1 8b 41 1b 7b 67 6f  be ca 43 df 7f 55 df 84   ...A.{go ..C..U..
  0002f0  7e 8a 7e e6 7e 71 e0 e9  39 cf aa 5a b7 f3 cd 5e   ~.~.~q.. 9..Z...^
  000300  c7 ba c6 c9 8a 2e d5 8c  0e 0f 9c 70 d2 a3 d2 d7   ........ .,.p....
  000310  e3 5c ac df 74 33 8f bb  b7 20 a6 01 22 55 55 47   .\..t3.. . .."UUG
  000320  89 13 b7 0c 70 20 84 e8  76 d5 a9 5e 65 3c 60 c1   ....p .. v..^e<`.
  000330  8b c5 2a 61 36 72 c5 16  e1 ce 4f 45 db f7 f3 85   ..*a6r.. ..OE....
  000340  e1 45 94 9b 46 75 26 8e  6e 09 a2 1a 36 71 b7 45   .E..Fu&. n...6q.E
  000350  4f 22 a4 fa 11 70 1d cd  c4 d7 01 0f 4b 56 43 5d   O"...p.. ...,KVC]
  000360  3d 27 63 66 41 de 90 68  28 62 04 c8 4e 0b 5d 2d   ='cfA..h (b..N.]-
  000370  8d 55 58 78 47 2b 5f d6  40 cc af b9 7f 0b 1d 02   .UXxG+_. @.......
  000380  e4 9a 4f 38 e7 d2 7a a2  51 5d f6 62 16 6e 42 5b   ..O8..z. Q].b.nB[
  000390  0f da 60 c6 33 6b 69 4a  40 50 f1 5c 69 36 44 e9   ,.`.3kiJ @P.\i6D.
  0003a0  af 5f cf f3 05 da 45 4c  ca 22 40 4f c8 6e 95 66   ._....EL ."@O.n.f
  0003b0  5d 1d fa ad 53 98 e2 7d  ba ad bb 8f 8c 5e 06 d3   ]...S..} .....^..
  0003c0  a4 63 b0 62 2a e4 86 6a  02 0e 07 48 ac 91 d4 c8   .c.b*..j ...H....
  0003d0  13 01 52 da a5 6d 1c a9  0c 4d dd 90 d1 eb df 15   ..R..m.. .M......
  0003e0  07 2b ba 3f 84 fb 72 c0  52 6c 5c dc 59 8a         .+.?..r. Rl\.Y.  
InitializeSecurityContext Token  { &buf= 001470B8, len= 1325 }
  000000  60 82 05 29 06 0a 2a 86  48 86 f7 12 01 02 02 03   `..)..*. H.......
  000010  01 00 6e 82 05 17 30 82  05 13 a0 03 02 01 05 a1   ..n...0. ........
  000020  03 02 01 0e a2 07 03 05  00 60 00 00 00 a3 82 04   ........ .`......
  000030  34 61 82 04 30 30 82 04  2c a0 03 02 01 05 a1 10   4a..00.. ,.......
  000040  1b 0e 43 45 52 54 2e 4d  53 41 44 53 2e 43 4f 4d   ..CERT.M SADS.COM
  000050  a2 1a 30 18 a0 03 02 01  01 a1 11 30 0f 1b 0d 61   ..0..... ...0,..a
  000060  64 6d 69 6e 69 73 74 72  61 74 6f 72 a3 82 03 f5   dministr ator....
  000070  30 82 03 f1 a0 03 02 01  17 a2 82 03 e8 04 82 03   0....... ........
  000080  e4 0a b2 f9 b8 47 d2 65  bb a3 3f 94 7a ff 85 ca   .....G.e ..?.z...
  000090  9d 2d 3a dc 63 c6 0c b5  f7 bb 95 50 71 b8 46 fa   .-:.c... ...Pq.F.
  0000a0  23 3c 5b 89 1d 23 b7 dc  ce 1c 15 27 1d e3 8b f6   #<[..#.. ...'....
  0000b0  90 db a5 e9 86 96 b7 65  fb 21 39 8f 91 ef d2 54   .......e .!9....T
  0000c0  70 40 91 a8 03 63 61 8e  76 59 d8 bf 9d 6b 73 1c   p@...ca. vY...ks.
  0000d0  da 28 56 9a 82 94 1d de  87 ca de 5f 8b bf 48 11   .(V..... ..._..H.
  0000e0  a1 b7 c9 61 15 48 c5 b6  f8 1a 40 cb c0 8f 1b a3   ...a.H.. ..@.....
  0000f0  d3 c5 2b 2d bb 01 d3 59  af e2 d1 dd bf d4 07 0a   ..+-...Y ........
  000100  68 4f 7d af c2 fe 9e 87  71 bf 16 8d 64 b7 f8 d6   hO}..... q...d...
  000110  45 71 44 1e 14 a1 fe 79  ec a1 16 19 01 41 38 b4   EqD....y .....A8.
  000120  ba db de 15 bf a5 9f 16  26 76 b0 6a c8 9c fc fc   ........ &v.j....
  000130  db 7d 80 f7 5b d0 f6 8c  24 8f e0 7f f0 91 8a eb   .}..[... $.......
  000140  a8 b0 5d f0 11 d5 5f ea  97 a4 d9 8f b5 f1 f7 eb   ..]..._. ........
  000150  89 eb cd 95 b2 88 b0 74  fb d2 9e e5 1c 30 96 75   .......t .....0.u
  000160  d4 4c 3a bc 9a d5 d0 7f  75 56 8f f3 38 a0 ce 2d   .L:..... uV..8..-
  000170  17 c2 89 7b 7c 11 8d 04  15 4d 12 d1 1c 8d 3f b9   ...{|... .M....?.
  000180  50 8a c0 31 4b b1 bf cc  6b c9 87 df cd fd 84 16   P..1K... k.......
  000190  27 1d fe aa c3 33 71 6b  f3 67 3a b6 27 f9 74 99   '....3qk .g:.'.t.
  0001a0  d3 91 d9 07 80 0a 1a d7  d3 4c 04 f0 81 7b bd da   ........ .L...{..
  0001b0  c7 c9 b9 30 64 f4 07 28  28 67 18 db aa 6d 65 9a   ...0d..( (g...me.
  0001c0  d5 c4 3a 74 a4 b9 b9 ac  ff b3 59 22 cf 68 f8 e2   ..:t.... ..Y".h..
  0001d0  16 bf b6 58 41 d4 a5 77  39 fc 2f 53 46 fa 25 5e   ...XA..w 9./SF.%^
  0001e0  dd 6a eb 79 f0 fc c4 ad  80 f0 84 75 ae e9 71 f6   .j.y.... ...u..q.
  0001f0  12 90 e3 ca 08 24 f7 17  90 84 1e 9f a4 2f ad eb   .....$.. ...../..
  000200  9d f8 e4 a9 aa 6e 29 f0  91 de e5 2a 28 69 92 e5   .....n). ...*(i..
  000210  ef 72 bc 44 70 82 f8 b4  f1 a9 ee ad 0c b5 62 28   .r.Dp... ......b(
  000220  af 51 da 62 9c e5 06 3a  8c 12 a4 4f 09 e3 77 c6   .Q.b...: ...O..w.
  000230  f6 04 97 13 cd 6a 09 7c  d0 81 b3 cd 19 82 6d 03   .....j.| ......m.
  000240  b6 24 6f 85 a5 04 77 f8  03 c2 0f f6 10 5d fc 6b   .$o...w. ..,..].k
  000250  a4 95 1e 63 62 c6 7f 8b  37 3f 3e 24 fb 86 93 bc   ...cb... 7?>$....
  000260  35 ce 33 88 96 dc e0 a0  b4 22 92 c4 9c da 3e b4   5.3..... ."....>.
  000270  9d c7 2e da d6 b5 79 b4  c2 e3 a6 3b fa 47 c3 80   ......y. ...;.G..
  000280  2a 19 3e a3 af 91 0f 74  55 93 5b ad 6b 9c 29 85   *.>...,t U.[.k.).
  000290  2d 82 3c d2 b9 4f ba b2  d6 54 86 f3 58 17 95 33   -.<..O.. .T..X..3
  0002a0  4f 2a bd 4b 57 a4 90 b7  02 57 08 ab c5 cc 4f 64   O*.KW... .W....Od
  0002b0  1e 76 ac 6c d2 02 46 52  ff f9 04 fc ca 6d 46 0f   .v.l..FR .....mF,
  0002c0  f3 16 22 fd 7a e0 15 10  05 b3 3b 5e 1e ae f6 54   ..".z... ..;^...T
  0002d0  f3 60 03 af 3f d9 c0 e3  ac 8a fa 7d a3 c3 b8 7a   .`..?... ...}...z
  0002e0  69 21 18 39 04 95 94 4a  e1 6d 54 36 71 26 78 3d   i!.9...J .mT6q&x=
  0002f0  e9 3c 25 e3 7e 4e 50 59  95 20 00 4f 85 f5 7c 53   .<%.~NPY . .O..|S
  000300  66 f7 d1 0f 42 10 5e 74  b8 0b de 69 e8 75 6f 2d   f..,B.^t ...i.uo-
  000310  1a 7c 24 d7 e9 9c df 29  8b 17 b1 ad c3 6a f8 b2   .|$....) .....j..
  000320  4e 7a b5 99 a1 c7 bf b0  41 39 92 91 8e f3 c8 2a   Nz...... A9.....*
  000330  65 7a e2 03 4f b8 9f e2  df 6a 3e 9b 8f a8 94 12   ez..O... .j>.....
  000340  5b 64 98 87 81 03 fa b2  81 6c 98 38 9c 86 0a 9a   [d...... .l.8....
  000350  8d e0 c0 6d 31 d7 34 45  a6 f7 63 42 4d ac b1 1c   ...m1.4E ..cBM...
  000360  bb ca 15 ec ab f4 48 3c  8c 1c 5f 40 55 59 47 c5   ......H< .._@UYG.
  000370  66 e7 01 6e 7d e5 27 b0  52 35 0c 70 ab 70 5c e8   f..n}.'. R5.p.p\.
  000380  c6 0d 70 6e 3d d1 8e 8d  3b 8d ed 8f 84 02 2e e5   ..pn=... ;.......
  000390  6d 85 8b e2 b2 c2 58 82  16 f2 ff 5a 4f 93 05 3b   m.....X. ...ZO..;
  0003a0  05 65 28 24 5c 31 bc 89  0d 22 4d d3 74 eb fa 9e   .e($\1.. ."M.t...
  0003b0  f9 9f 95 3a 27 ef e5 f9  ed 86 09 0c 26 1a d6 73   ...:'... ....&..s
  0003c0  3e 7a 52 e9 dc 74 a3 9a  13 01 ec 34 32 5b eb 86   >zR..t.. ...42[..
  0003d0  93 5c e3 11 9f 6d 14 e7  e2 d0 7f 30 db 88 c9 39   .\...m.. ...0...9
  0003e0  d3 bd 6c 70 2d cb 1d 31  52 1e 69 d2 24 69 64 c0   ..lp-..1 R.i.$id.
  0003f0  59 87 72 24 55 44 47 d3  47 a6 3d a6 6e 58 b4 51   Y.r$UDG. G.=.nX.Q
  000400  a6 70 9b 2e a9 d0 f9 b5  0e 4a 19 93 2c ba 7b 64   .p...... .J..,.{d
  000410  67 53 81 19 ad 54 5a 42  6a 90 95 34 f1 fe 77 65   gS...TZB j..4..we
  000420  53 cc 77 c8 86 f4 4c c8  30 b6 51 02 88 e8 f8 1d   S.w...L. 0.Q.....
  000430  b5 65 e2 f1 68 84 9f 61  15 f3 d3 b6 03 60 ff 21   .e..h..a .....`.!
  000440  c8 79 42 b0 6d a5 30 17  67 a8 ab b9 da 3a c4 6d   .yB.m.0. g....:.m
  000450  49 2d aa 2d 55 88 c9 87  be e1 d5 12 3b fc 83 bc   I-.-U... ....;...
  000460  3e 39 96 f3 d7 a4 81 c5  30 81 c2 a0 03 02 01 17   >9...... 0.......
  000470  a2 81 ba 04 81 b7 6d 59  0d 7f a4 84 52 72 ed ae   ......mY ....Rr..
  000480  6b 64 fe 32 43 b1 ff 83  38 e5 bb 66 4f ea 03 fb   kd.2C... 8..fO...
  000490  37 84 7e 0e f2 bb ab 5f  de 31 a7 3b 36 0b 6e 3a   7.~...._ .1.;6.n:
  0004a0  b5 e8 20 62 3a 2d e6 78  8c d7 08 e5 6c 77 66 58   .. b:-.x ....lwfX
  0004b0  4e 55 39 51 ed 73 0e 2b  f5 ba 08 71 ce 04 97 fb   NU9Q.s.+ ...q....
  0004c0  3c e5 24 fc 67 fc ab 2b  7e 57 90 c2 9d 8d 3a 22   <.$.g..+ ~W....:"
  0004d0  a1 5e 80 eb 5e 73 e2 3f  f7 e4 fc 70 ec 64 14 70   .^..^s.? ...p.d.p
  0004e0  3e d2 11 7e e8 d3 cd 23  18 32 37 7b c9 00 9f 0e   >..~...# .27{....
  0004f0  4f 58 27 27 17 fa 9d d4  aa 8b 77 7b 67 16 3d c0   OX''.... ..w{g.=.
  000500  bd 17 56 53 be 9e 42 5b  60 2e 8a c3 a3 59 03 74   ..VS..B[ `....Y.t
  000510  10 a8 e5 b4 9c 0c 77 45  1f 80 0a 9c af 64 30 43   ......wE .....d0C
  000520  14 26 f9 dd a5 4f ce ef  bc 29 76 75 0f            .&...O.. .)vu,   
AcceptSecurityContext Token  { &buf= 00149FA0, len= 135 }
  000000  60 81 84 06 0a 2a 86 48  86 f7 12 01 02 02 03 02   `....*.H ........
  000010  00 6f 74 30 72 a0 03 02  01 05 a1 03 02 01 0f a2   .ot0r... ......,.
  000020  66 30 64 a0 03 02 01 17  a2 5d 04 5b a4 a9 05 23   f0d..... .].[...#
  000030  f5 17 ff 73 ae 97 4b 4e  e4 d0 5f 47 17 52 94 95   ...s..KN .._G.R..
  000040  15 2e 88 2b bc b7 76 ef  f1 91 43 10 22 f2 5c d1   ...+..v. ..C.".\.
  000050  01 7a ce 7f f7 91 1d ff  5f 4f f5 5a a6 06 17 a0   .z...... _O.Z....
  000060  85 40 7c b2 e8 62 21 e5  1a 49 d4 f0 6e 07 6a 42   .@|..b!. .I..n.jB
  000070  b4 43 99 42 d9 0a a1 c6  71 7c 20 4d c1 be 2a cf   .C.B.... q| M..*.
  000080  50 3d c6 dc d5 ff a6                               P=.....          
Client authenticated to Server with Name "CERT\Administrator".
Client authenticated to Server with native Name "[email-masked]".

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 7 Oct 2003 09:48:36 -0700

> the acceptor is rfc-1964 or rfc-1964bis.

I agree.

Does this mean that because of prot_ready we cannot really remove the
framing from per-msg tokens either?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 7 Oct 2003 11:49:39 -0500

> framing from per-msg tokens either?

Er, never mind - forget I wrote the above.  'Twas a thinko.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 7 Oct 2003 19:00:12 +0200 (MET DST)

> but we would be shocked if we have not tested interoperability before

My primary interoperability concern is between implementations of
the new protocol and installed base of rfc-1964!

---

From: Martin Rex <[email-masked]>
Date: Tue, 7 Oct 2003 22:15:35 +0200 (MET DST)

> and current implementers of the spec seem to believe it is a good

Could you elaborate more on the "believe it is a good idea".

rfc-1964 section 1.1 says:

   The above GSS-API framing shall be applied to all tokens emitted by
   the Kerberos V5 GSS-API mechanism, including KRB_AP_REP, KRB_ERROR,
   context-deletion, and per-message tokens, not just to the initial
   token in a context establishment sequence.  While not required by
   RFC-1508, this enables implementations to perform enhanced error-
   checking.

I do violently agree that having the generic outer framing is
extremely valuable in error-checking (including recognizing and reporting
misbehaviour of a Kerberos (gssapi) mechanism).

Repeating myself: since dropping the code is NOT an option, it is
required for backward compatibility with the installed base,
what are the real benefits that outweigh the added complexity
and the risk of non-interoperability with implementation that
are not sufficiently tested before being shipped?

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Tue, 07 Oct 2003 16:53:05 -0400

Martin> Sam Hartman wrote:
    >>  No, oops we should have called it out on the list.  The draft
    >> authors and current implementers of the spec seem to believe it
    >> is a good idea.

    Martin> Could you elaborate more on the "believe it is a good
    Martin> idea".

Sure.  We believe that having the header size of per-message tokens be
non-constant is non-ideal.  For Microsoft it creates some memory
alignment issues.

for the rest of us, we don't see any benefit in having the DER header
present.

I continue to not buy the complexity argument very much, especially
for per-message tokens.

---

From: Martin Rex <[email-masked]>
Date: Wed, 8 Oct 2003 19:11:33 +0200 (MET DST)

> non-constant is non-ideal.  For Microsoft it creates some memory

memory alignment issues for Microsoft?  I don't buy that right away!

EncryptMessage() in Microsoft's SSPI takes three seperate
application-supplied buffers, DecryptMessage() takes a
single application-supplied buffer -- and I'm not aware
of any alignment requirements for those buffers...

> for the rest of us, we don't see any benefit in having the DER header

This is not about taste.  Taste may have been an issue when
rfc-1964 was discussed.  We're discussing technical necessities
for a change from what rfc-1964, and I haven't seen any good
reason so far -- size was a reason that had been discussed on
CAT when thinking about gss-api protected telnet sessions,
but you indicated yourself that size wasn't really an issue for you.

> I continue to not buy the complexity argument very much, especially

Wait a minute -- I don't buy that changing this characteristic
of rfc1964 is sufficiently justified so far.  Those who want to
change it have to come up with a good reason for it, not the
other way round.

You have to consider all those implementors who never participate
in the IETF process, and for them it will be undoubtedly easier
to implement if there's only a single codepath.

17 of 20 Implementors of gssapi mechanisms that have certified
for interoperability with our application have never participated
the IETF, they only took the final RFC and tried to implement
what was specified.  And that is the real purpose of a standard.

If the members of the kerbers working group really think that
they're the only ones who will implement that standard and therefore
whatever is fine with them implementors must be fine for everyone
else, then this work should no longer be continued within
the IETF.  The purpose of the IETF is explicitly to produce standards
that others who didn't participate in the standardization will
be able to implement easily and correctly. 

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Wed, 08 Oct 2003 13:37:41 -0400

Martin> Sam Hartman wrote:
    Martin> This is not about taste.  Taste may have been an issue
    Martin> when rfc-1964 was discussed.  

Strongly disagree.  One of my requirements for going along with a new
GSSAPI mechanism is more tasteful than RFC 1964.

Compatibility with RFC 1964 is not something I care about for this
mechanism.  Anti-compatibility with RFC 1964 has been an explicit goal
in my mind for parts of this mechanism design.

We are never going to agree on the issue of how important RFC 1964
compatability is and on to what extent taste matters in this mechanism
design.  Let's not try.  Instead let's see if we can find a compromise
on the specific technical details that both of us can live with.