Sam,

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
> Of Sam Hartman
> Sent: Thursday, March 31, 2011 10:03 AM
> To: [email protected]
> Subject: [abfab] Message Integrity for gss-eap
> 
> 
> 
> Folks, during today's meeting we discussed the need for protecting
> information exchanged during the context exchange.
> 
> An example of this need would be protecting context flags from the client
to
> the server.
> Some server implementations require that certain context flags be set.
> As an example ssh servers following RFC 4462 require the mutual flag be
set.
> This needs to be integrity protected.
> 
> There are a number of possible options:
> 
> 1) Integrity protect each token separately. Down side: more complex
> especially if tokens need integrity protection that are exchanged before a
> key is available.

I think there is another possible downside here that needs to be considered,
without having a mic on all of the data that you are trying to protect,
there is a possibility that either something that should be mic-ed isn't or
something that is mic-ed is removed from the set.

Jim

> 
> 2) Extend our mechanism to depend on a specific hash function.
> Disadvantage: requires us dealing with crypto primitives directly . Adds
> complexity to specificiation of the mechanisms.
> 
> 3) Provide a gss_getmic or similar of the entire conversation.  The
> disadvantage here is that the client needs to maintain state sufficient to
hold
> a copy of the conversation. If there is a stateless server, this
ever-increasing
> state needs to be transported back and forth for each message.
> 
> --Sam
> _______________________________________________
> abfab mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/abfab

_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab

Reply via email to