Hi Hongwei, > We finished adding an example for GSS_WrapEx with > AES128-CTS-HMAC-SHA1-96 in [MS-KILE]. The attached PDF document is the > newly added section(4.3) of the [MS-KILE] document. > > We really appreciate your suggestion. Please let us know if you have > further questions regarding this subject.
It would be nice if this example would use ec != 0, as that was exactly not match RFC 4121 and the reason our (heimdal) krb5 code was not able to handle network traffix from windows. You should unify the naming of the resulting overhead, in the diagramm you use 'checksum' and in the test you use 'signature', maybe 'token' would be the better word here, as 'checksum' is a non unique in the diagramm. An example with arcfour-hmac-md5 would also be very useful, as there the pseudo ASN.1 wrapping arround the token is very tricky. As it's only arround the 'token' instead of 'token' + 'message' + 'padding' as it is for the standard GSS_Wrap function. Also it would be nice to have a specific example how the RPC layer calls GSS_WrapEx. It would also be very helpfull to know how the mapping to the SSPI function parameters works. metze > > ---------------------------------------------------------- > Hongwei Sun - Sr. Support Escalation Engineer > DSC Protocol Team, Microsoft > [EMAIL PROTECTED] > Tel: 469-7757027 x 57027 > ----------------------------------------------------------- > > > > -----Original Message----- > From: Andrew Bartlett [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 27, 2008 6:24 AM > To: Hongwei Sun > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: [Pfif] [cifs-protocol] Clarify AEAD behaviour for GSSAPI with > AES > > On Tue, 2008-08-26 at 08:50 -0700, Hongwei Sun wrote: >> Andrew, >> >> In this case, you provided a diagram for us to add to the document and >> metze added some comments. Thanks for your contribution to our >> documentation and continued feedback. >> >> The product team reviewed the diagram and comments provided. We believe >> that the diagrams imply interaction between elements and without >> detailed notes they are subject to multiple interpretation and hence >> confusion. We believe that as a matter of providing deterministic >> documentation, we would prefer to provide specific examples. >> >> We'll be happy to get your feedback on creating examples and send them >> for your review once they are ready. > > A visual description of how the RRC interacts with the AEAD behaviour and > the subsequent placement of the trailer in the header will be critical. > > Andrew Bartlett > > -- > Andrew Bartlett > http://samba.org/~abartlet/ > Authentication Developer, Samba Team http://samba.org > Samba Developer, Red Hat Inc. > _______________________________________________ > Pfif mailing list > [EMAIL PROTECTED] > http://lists.tridgell.net/cgi-bin/mailman/listinfo/pfif > _______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol