> Initially I thought this meant removing the seed entirely from S/Key. > Mudge clarified this to me by explaining that what he meant was removing > the routine presentation of the seed in the login challenge, but > continuing to use it internally. It would still be necessary to present > a new seed in the process of renewing one's S/Key sequence, so while the > seed is still exposed, the amount of repeat exposure would be > significantly reduced. This is at least quite a bit better than what I > thought he meant before. There are some pros and cons to removing the seed. Consider if we were to remove it. In this case, we would need to be there when we renew the keys. The renewing process would then tell us what our seed is and we could record this. (in a palm pilot, for example). The danger in this is if we lose the key. I presume you could have a function that would tell you, but if you are not on the machine, that won't work. I am in favor of the more secure option, but it may not fit the needs of all. > Ultimately I wonder how much of a future S/Key has now that SSH and > similar utilities are widely deployed and provide much more > sophisticated protections, especially session encryption. I think there is definatly still a need. There are many cases in which I am not on a machine what has ssh (ie some public telnet shell). Though the session is not encrypted, my password is still safe. Until ssh-java shells are common, s/key still has it's place. - merlin SCL Manager, CWRU bat_private 216.368.5066 pgp key: clabs.cwru.edu/b.pgp
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:31:55 PDT