> Maybe this is just a stupid question, but do they really need to maintain > state of the entire conversation? I mean, both parties could just maintain > the result of a hash over the conversation so far, built in an iterative way. > Something like this: > > state' = hash (state, new_message) > > At the end of the conversation, they could compute GSS_mic over the state. > > May be the overload of computing such hashes is worse than the memory needed > to store the entire state.
It's not this so much. The problem is hash agility: we want GSS EAP to use the crypto primitives provided by RFC 3961, and this does not have a primitive for incrementally updating a checksum. So, we could extend RFC 3961 (which, wearing my implementors' hat, will involve some fairly intrusive changes to the popular Kerberos implementations). Or we could use a fixed checksum algorithm, but that's brittle and makes the entire protocol vulnerable if a weakness is ever discovered. Or we could build in some mechanism for negotiating checksum algorithms, but that risks re-inventing the wheel. Sam or Nico can explain this better than I, I'm sure. -- Luke _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
