Re: [Pfif] [cifs-protocol] Clarify AEAD behaviour for GSSAPIwith AES
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
RE: [Pfif] [cifs-protocol] Clarify AEAD behaviour for GSSAPIwith AES
Stefan, I like to give you an update on the issues and suggestion in your e-mail. >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. We are in the process of incorporating your suggestion into the diagram. It is in the review stage of document update. >You should unify the naming of the resulting overhead, in the diagram >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 diagram. Thanks for pointing out the inconsistency. We will fix it in the update we are working on. >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. I filed a formal request for the documentation team to consider your suggestion. I will let you know once I hear back from them. >Also it would be nice to have a specific example how the RPC layer >calls GSS_WrapEx. There is an example in 4.1 [MS-RPCE] that describes how various GSS-API calls, including GSS_WrapEx and GSS_unWrapEx, are called in a secure and connection-oriented RPC call using Kerberos as security provider. Please review the section and let us know if it is what you are looking for. >It would also be very helpfull to know how the mapping to the SSPI >function parameters works. MSDN has all the information about SSPI , including EncryptMessage() and DecryptMessage(), on http://msdn.microsoft.com/en-us/library/aa375378(VS.85).aspxThere is also a MSDN article for SSPI Interoperability with GssAPI (http://msdn.microsoft.com/en-us/library/ms995352.aspx). This document is about how the protocol works and the description of SSPI should not be a normative reference for the protocol documentation. Thanks ! Hongwei -Original Message- From: Stefan (metze) Metzmacher [mailto:[EMAIL PROTECTED] Sent: Sunday, October 19, 2008 10:03 AM To: Hongwei Sun Cc: Andrew Bartlett; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [Pfif] [cifs-protocol] Clarify AEAD behaviour for GSSAPIwith AES 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
RE: [Pfif] [cifs-protocol] Clarify AEAD behaviour for GSSAPIwith AES
metze, I just want to check to see if you have any more feedback about the latest update of diagram and text. If you don't have any more questions, I will close the case regarding Gss_WrapEx with AES128-CTS-HMAC-SHA1-96 in MS-KILE. Thanks -- Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft hongw...@microsoft.com Tel: 469-7757027 x 57027 --- -Original Message- From: Hongwei Sun Sent: Tuesday, December 30, 2008 10:26 AM To: 'Stefan (metze) Metzmacher' Cc: Andrew Bartlett; p...@tridgell.net; cifs-proto...@samba.org Subject: RE: [Pfif] [cifs-protocol] Clarify AEAD behaviour for GSSAPIwith AES Stefan, We have updated the example for GSS_WrapEx with AES128-CTS-HMAC-SHA1-96 in MS-KILE as per your suggestion. I attached the updated section 4.3 of MS-KILE for your review. Please also see the inline comment. We really appreciate your help for improving our Open Protocol Documentation. >-Original Message- >From: Stefan (metze) Metzmacher [mailto:me...@samba.org] >Sent: Sunday, October 19, 2008 10:03 AM >To: Hongwei Sun >Cc: Andrew Bartlett; p...@tridgell.net; cifs-proto...@samba.org >Subject: Re: [Pfif] [cifs-protocol] Clarify AEAD behaviour for >GSSAPIwith AES >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. We explicitly documented in the latest update that "right rotation by (EC+RRC) count" should be performed. >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. We fixed the inconsistency between text and diagram. >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. I already responded to you regarding these questions in a separate mail on 11/24/08. >metze Thanks -- Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft hongw...@microsoft.com Tel: 469-7757027 x 57027 --- ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [Pfif] [cifs-protocol] Clarify AEAD behaviour for GSSAPIwith AES
Hi Hongwei, >I just want to check to see if you have any more feedback about the latest > update of diagram and text. If you don't have any more questions, I will > close the case regarding Gss_WrapEx with AES128-CTS-HMAC-SHA1-96 in MS-KILE. The diagram and text look good, maybe add a notice that - right rotation by (EC+RRC) count - doesn't match the rfc, which says right rotation just by RRC count But please check with Larry if that behavior will stay for the non-dce-style case in future versions, there were some discussions about making the EC+RRC "feature" dce-style specific in future versions of windows. metze > -- > Hongwei Sun - Sr. Support Escalation Engineer > DSC Protocol Team, Microsoft > hongw...@microsoft.com > Tel: 469-7757027 x 57027 > --- > > > > > > -Original Message- > From: Hongwei Sun > Sent: Tuesday, December 30, 2008 10:26 AM > To: 'Stefan (metze) Metzmacher' > Cc: Andrew Bartlett; p...@tridgell.net; cifs-proto...@samba.org > Subject: RE: [Pfif] [cifs-protocol] Clarify AEAD behaviour for GSSAPIwith AES > > Stefan, > >We have updated the example for GSS_WrapEx with AES128-CTS-HMAC-SHA1-96 in > MS-KILE as per your suggestion. I attached the updated section 4.3 of > MS-KILE for your review. Please also see the inline comment. > >We really appreciate your help for improving our Open Protocol > Documentation. > > >> -Original Message- >> From: Stefan (metze) Metzmacher [mailto:me...@samba.org] >> Sent: Sunday, October 19, 2008 10:03 AM >> To: Hongwei Sun >> Cc: Andrew Bartlett; p...@tridgell.net; cifs-proto...@samba.org >> Subject: Re: [Pfif] [cifs-protocol] Clarify AEAD behaviour for >> GSSAPIwith AES > >> 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. > > We explicitly documented in the latest update that "right rotation by > (EC+RRC) count" should be performed. > >> 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. > > We fixed the inconsistency between text and diagram. > >> 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. > > I already responded to you regarding these questions in a separate mail on > 11/24/08. > >> metze > > > > Thanks > > -- > Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft > hongw...@microsoft.com > Tel: 469-7757027 x 57027 > --- signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
RE: [Pfif] [cifs-protocol] Clarify AEAD behaviour for GSSAPIwith AES
Stefan, Thanks for the feedback. Please see the inline comments. >The diagram and text look good, maybe add a notice that >- right rotation by (EC+RRC) count - doesn't match the rfc, which says > right rotation just by RRC count I will discuss your suggestion with the documentation team. >But please check with Larry if that behavior will stay for the non-dce-style >case in future versions, there were some discussions about making the >EC+RRC "feature" dce-style specific in future versions of windows. I confirmed with the product team that there is no change planed in future releases in terms of EC+RRC handling logic. The existing behavior will stay. Thanks -- Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft hongw...@microsoft.com Tel: 469-7757027 x 57027 --- -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Thursday, January 08, 2009 1:29 AM To: Hongwei Sun Cc: Andrew Bartlett; p...@tridgell.net; cifs-proto...@samba.org Subject: Re: [Pfif] [cifs-protocol] Clarify AEAD behaviour for GSSAPIwith AES Hi Hongwei, >I just want to check to see if you have any more feedback about the latest > update of diagram and text. If you don't have any more questions, I will > close the case regarding Gss_WrapEx with AES128-CTS-HMAC-SHA1-96 in MS-KILE. The diagram and text look good, maybe add a notice that - right rotation by (EC+RRC) count - doesn't match the rfc, which says right rotation just by RRC count But please check with Larry if that behavior will stay for the non-dce-style case in future versions, there were some discussions about making the EC+RRC "feature" dce-style specific in future versions of windows. metze > -- > Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, > Microsoft hongw...@microsoft.com > Tel: 469-7757027 x 57027 > --- > > > > > > -Original Message- > From: Hongwei Sun > Sent: Tuesday, December 30, 2008 10:26 AM > To: 'Stefan (metze) Metzmacher' > Cc: Andrew Bartlett; p...@tridgell.net; cifs-proto...@samba.org > Subject: RE: [Pfif] [cifs-protocol] Clarify AEAD behaviour for > GSSAPIwith AES > > Stefan, > >We have updated the example for GSS_WrapEx with AES128-CTS-HMAC-SHA1-96 in > MS-KILE as per your suggestion. I attached the updated section 4.3 of > MS-KILE for your review. Please also see the inline comment. > >We really appreciate your help for improving our Open Protocol > Documentation. > > >> -Original Message- >> From: Stefan (metze) Metzmacher [mailto:me...@samba.org] >> Sent: Sunday, October 19, 2008 10:03 AM >> To: Hongwei Sun >> Cc: Andrew Bartlett; p...@tridgell.net; cifs-proto...@samba.org >> Subject: Re: [Pfif] [cifs-protocol] Clarify AEAD behaviour for >> GSSAPIwith AES > >> 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. > > We explicitly documented in the latest update that "right rotation by > (EC+RRC) count" should be performed. > >> 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. > > We fixed the inconsistency between text and diagram. > >> 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. > > I already responded to you regarding these questions in a separate mail on > 11/24/08. > >> metze > > > > Thanks > > -- > Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, > Microsoft hongw...@microsoft.com > Tel: 469-7757027 x 57027 > --- ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
RE: [Pfif] [cifs-protocol] Clarify AEAD behaviour for GSSAPIwith AES
metze, Since RRC as specified in section 3.4.5.4.1 in MS-KILE is different than what is defined in RFC4121, we will not be adding an additional notes. Thanks for your suggestion. Hongwei -Original Message- From: Hongwei Sun Sent: Friday, January 09, 2009 5:19 PM To: 'Stefan (metze) Metzmacher' Cc: Andrew Bartlett; p...@tridgell.net; cifs-proto...@samba.org Subject: RE: [Pfif] [cifs-protocol] Clarify AEAD behaviour for GSSAPIwith AES Stefan, Thanks for the feedback. Please see the inline comments. >The diagram and text look good, maybe add a notice that >- right rotation by (EC+RRC) count - doesn't match the rfc, which says > right rotation just by RRC count I will discuss your suggestion with the documentation team. >But please check with Larry if that behavior will stay for the non-dce-style >case in future versions, there were some discussions about making the >EC+RRC "feature" dce-style specific in future versions of windows. I confirmed with the product team that there is no change planed in future releases in terms of EC+RRC handling logic. The existing behavior will stay. Thanks -- Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, Microsoft hongw...@microsoft.com Tel: 469-7757027 x 57027 --- -Original Message- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Thursday, January 08, 2009 1:29 AM To: Hongwei Sun Cc: Andrew Bartlett; p...@tridgell.net; cifs-proto...@samba.org Subject: Re: [Pfif] [cifs-protocol] Clarify AEAD behaviour for GSSAPIwith AES Hi Hongwei, >I just want to check to see if you have any more feedback about the latest > update of diagram and text. If you don't have any more questions, I will > close the case regarding Gss_WrapEx with AES128-CTS-HMAC-SHA1-96 in MS-KILE. The diagram and text look good, maybe add a notice that - right rotation by (EC+RRC) count - doesn't match the rfc, which says right rotation just by RRC count But please check with Larry if that behavior will stay for the non-dce-style case in future versions, there were some discussions about making the EC+RRC "feature" dce-style specific in future versions of windows. metze > -- > Hongwei Sun - Sr. Support Escalation Engineer DSC Protocol Team, > Microsoft hongw...@microsoft.com > Tel: 469-7757027 x 57027 > --- > > > > > > -Original Message- > From: Hongwei Sun > Sent: Tuesday, December 30, 2008 10:26 AM > To: 'Stefan (metze) Metzmacher' > Cc: Andrew Bartlett; p...@tridgell.net; cifs-proto...@samba.org > Subject: RE: [Pfif] [cifs-protocol] Clarify AEAD behaviour for > GSSAPIwith AES > > Stefan, > >We have updated the example for GSS_WrapEx with AES128-CTS-HMAC-SHA1-96 in > MS-KILE as per your suggestion. I attached the updated section 4.3 of > MS-KILE for your review. Please also see the inline comment. > >We really appreciate your help for improving our Open Protocol > Documentation. > > >> -Original Message- >> From: Stefan (metze) Metzmacher [mailto:me...@samba.org] >> Sent: Sunday, October 19, 2008 10:03 AM >> To: Hongwei Sun >> Cc: Andrew Bartlett; p...@tridgell.net; cifs-proto...@samba.org >> Subject: Re: [Pfif] [cifs-protocol] Clarify AEAD behaviour for >> GSSAPIwith AES > >> 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. > > We explicitly documented in the latest update that "right rotation by > (EC+RRC) count" should be performed. > >> 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. > > We fixed the inconsistency between text and diagram. > >> 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&#
