Theoretically I agree whole heartedly. In practice we were engaged in an audit and would not have been succesful without the seed (I appologize for my terminology but I look at the decrementing counter as the counter and the fixed value for the iterations as the seed here). People need to learn from both the theoretical and the practical - neither work in a vacuum. cheers, .mudge On Tue, 25 Jan 2000, Steve VanDevender wrote: > Mudge writes: > > Ahhh but here was my concern back in 95/96 which appears to still be > > valid: > > > > Given that you know what machine you are connecting to, the use of the > > seed in the S/key challenge is not as necessary to present to the end user > > as it might be otherwise. > > > > Thus - server: abc123 challenge: s/key 99 K113356 > > > > could be reduced to server: abc123 challenge: s/key 99 as presented to the > > user. This would make the current dictionary attacks largely unusable as > > there is a secret that is required but unknown to the attacker. > > The point of having the seed (or challenge word, as I referred to it > previously) in the challenge is that when the sequence number in the > challenge becomes low, one can start a new sequence using a different > seed without the user having to change his S/Key secret. The rationale > is quite clearly described in the RFC. The seed is not anything like a > secret and was never intended to identify the server being connected to, > and removing it is not beneficial to the S/Key protocol. Removing the > seed does not make dictionary attacks on the user's secret harder, let > alone "largely unusable". At best it might force the user to choose > different secrets once in a while to restart their sequences, but if the > user is already inclined to use poor secrets, it's still not improving > security significantly. > > Ultimately the security of S/Key depends on whether the user's secret > remains secret. The choice of a good secret that is not susceptible to > a dictionary attack, then defending the secret against exposure, is the > only real way to ensure S/Key's security. >
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:31:35 PDT