Date: Sat, 14 Aug 1999 13:52:53 -0700 From: Nick Sayer <nsayer@quack.kfu.com> To: Kris Kennaway <kris@hub.freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Whither makefiles for src/crypto/telnet/* ? Message-ID: <37B5D725.7916E60@quack.kfu.com> References: <Pine.BSF.4.10.9908141139440.78768-100000@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a cryptographically signed message in MIME format. --------------ms074A2EC0F1507B2B602C4515 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kris Kennaway wrote: > > On Sat, 14 Aug 1999, Nick Sayer wrote: > > > Kris Kennaway wrote: > > > > > > On Fri, 13 Aug 1999, Dave Walton wrote: > > > > > > > If you really want to work on an encrypted telnet, check out The > > > > Stanford SRP Authentication Project (http://srp.stanford.edu/srp/). > > > > I'd love to see SRP integrated into the FreeBSD telnet/telnetd. > > > > > > I got started on this, to the extent of storing the SRP data in the passwd > > > file as an additional password crypt() method > > > > That will be incompatible with folks who, for example, use the old > > style passwords in a YP map in order to be compatible with other > > platforms > > in the same domain. > > By definition you cannot get around the need to store additional > authentication information to use SRP - it uses large integer mathematics > "along the lines of" RSA public-key cryptography to authenticate the user > securely, so it's not transparent as you correctly note. > > Using YP to share the password maps is problematic, since SRP "passwords" > have a different format than other algorithms. I don't know enough about > YP to speak on this, but if you can get away with sharing an > arbitrary-length "password hash" over YP then all SRP-capable clients can > use it. > > That's not the point, though - if you want to use legacy computer > platforms, you have to expect to use legacy passwords. The point is that you can do so AND have an increase in security of communications. Is the result perfect? No. Is it better than sending it in the clear? Yes. Is it JUST AS EASY for everyone concerned as sending it in the clear? Yes. So it's just as easy to do a little as do nothing. Why, then, is it considered so horrible to have the option of doing a little? > I haven't looked at > the SRA algorithm, but it's not obvious to me how you can simultaneously > provide a well-encrypted (against an attacker who is watching the setup > phase) session, and at the same time only use the (traditional UNIX) > password and hash. I would be happy to answer that. You do a traditional Diffie-Hellman. You use the resulting shared secret to send the username and password from client to server, DES encrypted. The resulting shared secret can also be used as a DES (or other) key for session encryption after you're done. It is vulnerable to MiM. I have said as such a dozen times now. It should be painfully obvious that plaintext sessions are vulnerable to a hell of a lot more than just that. > At the best all you're doing is obfuscating the data > stream, which becomes dangerous if people think of it as "encrypted > telnet". Of course, I may well be wrong - do you have a pointer to a paper > describing the SRA algorithm? No, but I have the source and have made it available to anyone inside the US. I have also stated that it is available outisde the US, so anyone could use their favorite search engine and get it. > > > As long as you require a shared secret there will be either extra > > overhead > > to maintain it (in a separate password database) or an exclusion of some > > platforms because of inabilities to generate the shared secret (because > > they have different crypt()s than we do). > > > > Not requiring a shared secret allows monkey-in-the-middle. But the goal > > here is to do better than nothing at all while not adding any > > administrative > > overhead. If you add overhead, people won't use it. > > With a SRP-capable client and server, the client need know nothing other > than the password entered by the user. Agreed. > The server is configured at > passwd(8) time. This is the beauty of SRP - it IS transparent, while at > the same time being "secure" in the ways which a plaintext or CHAP > authentication is not (I don't have references to the papers which > describe the benefits of SRP handy, but I could find them if needed). I will easily conceed that SRP is more secure than SRA. But I disagree that it is as transparent as you claim. S/Key comes with FreeBSD. How many FreeBSD users use it? Never mind even that, how many people reading this e-mail use it? > Once you have authenticated, you can use that to negotiate a session key, > which can be used to encrypt the remainder of the session. Same with SRA. > If you have a non-SRP client, you can still authenticate against the > server using a plaintext password, and treating the server-side data as a > fancy password hash, but you obviously lose all the benefits (as well as > compromising your password if you use it from both types of client) There are other costs, however. Your SRP equipped host cannot participate in a heterogenous YP environment without maintaining SRP passwords separately (and killing the purpose of YP in the process). Even in a homogenous YP environment you have to synchronize valuse of N and g (according to the Stanford web site) throughout the organization. > > > SRA is a compromise > > between security and ease of use. "Compromise" is not a four letter > > word. > > Many would argue that in the language of cryptography and data > encryption, the word "compromise" has only one meaning. So you would rather that plaintext be the only available option that requires no overhead? How is anyone better served by that? Why are you so opposed to an incremental step towards better security? --------------ms074A2EC0F1507B2B602C4515 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKpwYJKoZIhvcNAQcCoIIKmDCCCpQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CDMwggT9MIIEZqADAgECAhA9k/AV3oVH5b8fAYqgipwKMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTk5MDYyMTAwMDAw MFoXDTAwMDYyMDIzNTk1OVowggEYMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxGjAYBgNVBAMUEU5pY2hvbGFzIFcuIFNheWVyMSMwIQYJ KoZIhvcNAQkBFhRuc2F5ZXJAcXVhY2sua2Z1LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAwZ76sB91nFO45ERwMDwTiQLzF9SS68cGUY8LoVgVUY2R/8DfXJhBxDOEDXfM0pJj dtz4h6VTcP4LBP4R9eeanpz9rFhAuTHppFEM7mrz5ak+RNTYszlNJxFd/dm7Rlz9rgVCobHQ sh2Asg06t/l7CTgcY4yd78SxUGwNjW/kveECAwEAAaOCAY8wggGLMAkGA1UdEwQCMAAwgawG A1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEB Gj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3 IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDCBhgYKYIZIAYb4RQEGAwR4FnZkNDY1MmJk NjNmMjA0NzAyOTI5ODc2M2M5ZDJmMjc1MDY5YzczNTliZWQxYjA1OWRhNzViYzRiYzk3MDE3 NDdkYTVkM2YyMTQxYmVhYzIzZWMyZmQ4MjBiYWI2ZGY1ZDcxMTQ5OWZhMWJjNDRmNWYzZWE0 NTBjMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5j cmwwDQYJKoZIhvcNAQEEBQADgYEAUMq/Dtjh6qzf8sdDNxW6iDnN25VDyZMFgmfb0Epnh3Zi o/zeedJO4zm2/pvvLo8WiEsTTHdBimi3qn7eKaeA46EI9bev8Le2113//twTZhFWoKI1hebz /qTs7U/zLGM9zRD6cs2IagFPOVlRH65AoSo4MXgFu+HU/aUw1fpzbXIwggMuMIICl6ADAgEC AhEA0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5 WjCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5j b3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEg Q0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkq hkiG9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQWu1X9A3qKLZRPFXg2uA1Ksm+cVL+86Hcqnbnw aLuV2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0RcqkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhP h0q/Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqnsX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJ YIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcC ARYfd3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3T ymQ43BuYDAeGW4UVag+5SYWklfEXfWe0fy0s3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I 4xe1pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg5V+CprGoksVYasGNAzzrw80FopCubjGCAjww ggI4AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5 L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24g Q2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVk AhA9k/AV3oVH5b8fAYqgipwKMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNOTkwODE0MjA1MjU1WjAjBgkqhkiG9w0BCQQxFgQUW3dE Vne8rNi5j34nQ56tXFxiH1swUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG 9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZI hvcNAQEBBQAEgYCuGwSyatDh6rOpvsACU0wIO4ZdrQ6Lgh45TQYMR80QGTiOL9shOBNdAnUj up15xV0dPOMezntqjqqFgcVQ6JymdQyg4GNElarq5UKp9cJtNArBr/uDMBZEdeEQLetWj1QI 6zFKyoQzAHXlIsEOHcn/TBK6/tG8w9Gpsel+G81z2Q== --------------ms074A2EC0F1507B2B602C4515-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?37B5D725.7916E60>