[resend] On Mar 31, 2011 3:03 AM, "Sam Hartman" <[email protected]> wrote: > 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.
If this were the only unauthenticated plaintext requiring protection... then you could require that all such flags be set that the mechanism supports. > 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. You'd have to store or re-create those messages that come before kwy exchange. > 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. Also, hash agility. TLS 1.2 didn't do this in a well performing way and you'd have the same problem (you can't know a priori which hash function you'll negotiate, so you either use them all as you go or keep the messages. > 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. 4) Re-construct those messages near the end of the exchange, storing only iyems such as nonces in the interim. Nico -- _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
