Date: Sat, 14 Aug 1999 15:08:13 -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: <37B5E8CD.EBEFACDB@quack.kfu.com> References: <Pine.BSF.4.10.9908141412020.45940-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. --------------ms00CB884EF73ABC441C499DA5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kris Kennaway wrote: > > On Sat, 14 Aug 1999, Nick Sayer wrote: > > > > 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? > > Because the end-users won't understand this, and use the system as if it > was perfect, when in fact it provides few guarantees. The only thing it doesn't guarantee is that you won't get hit by MiM, and that someone won't spend a couple days to try and factor the DH exchange. It does guarantee (to the same strength as SRP) that your session won't get hijacked or sniffed. From where I sit you're not giving SRA enough credit for what it is capable of. > > > > 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 > > Where do you store the keys, or do you generate them dynamically? The > latter would take time to verify primality. If by "keys" you mean the DH generator and such, they are constants in the code at present. It is possible to extend the protocol in such a way as to pass them from server to client, but at present it does not do this. Having them be constant does not significantly weaken DH. If they weren't, you'd have to pass them from the server at session start. > This is also essentially the way SSL does it, without some of the protocol > overhead, and without trust verification of certificates. Sort of. SSL uses RSA to encrypt some data, because it requires the server to have a key pair (and the server public key must be certified). > > 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. > > Yup. > > > It should be painfully obvious that plaintext sessions are vulnerable > > to a hell of a lot more than just that. > > I agree. > > > > 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. > > Because it does not interoperate with legacy servers over NIS? Any other > reasons? If you're saying that you're going to have a new format of the second field of the master passwd file ($3$[^:]* ?), then I suppose the only other one left is having to convert legacy password files and manage the N and g values that SRP requires. You'll have to fix things that add users to have them default to the new scheme. And don't sniff at breaking NIS. Most sites I deal with use it. And I don't know of any site that uses NIS that isn't heterogenous, which requires the legacy password format. > > > S/Key comes with FreeBSD. How many FreeBSD users use it? Never mind even > > that, how many people reading this e-mail use it? > > One-time passwords have their own usability problems which make them not a > general-purpose solution. > > > 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. > > In my scheme I distribute these as part of the password "hash". N and g > are both public values known to both client and server(s). SRP has them in configuration files. They have to be set up. > > I also have prototype code which can store multiple password hashes in the > password file, and retrieves "secondaries" in a new field in struct > passwd. You could conceivably set it up to keep a DES password in sync > with the SRP one, and distribute only the DES over NIS. I don't know how > extensible NIS is, but maybe we could hide the other hashes in there as > well for those who understand them. NIS is not very extensible. It has too much history. > > > > 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? > > No, I favour going directly for a strong solution. Inter-operation via NIS > seems to be your only objection to SRP. And the mere existence of something better seems to be your only objection to SRA. Keep in mind, also, that as long as AUTHTYPE_SRP and AUTHTYPE_SRA are different numbers, both could be present. I would even conceed that SRP should be tried before SRA. But I'd sure as hell rather use SRA than nothing. > > Kris > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message --------------ms00CB884EF73ABC441C499DA5 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 MIIIYQYJKoZIhvcNAQcCoIIIUjCCCE4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Bg0wggLMMIICNaADAgECAgMBD9UwDQYJKoZIhvcNAQEEBQAwgbkxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMRowGAYDVQQKExFU aGF3dGUgQ29uc3VsdGluZzEpMCcGA1UECxMgVGhhd3RlIFBGIFJTQSBJSyAxOTk4LjkuMTYg MTc6NTUxNjA0BgNVBAMTLVRoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBSU0EgSXNzdWVyIDE5 OTguOS4xNjAeFw05OTA2MzAxODQ5MThaFw0wMDA2MjkxODQ5MThaMEYxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxIzAhBgkqhkiG9w0BCQEWFG5zYXllckBxdWFjay5rZnUu Y29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCtPesTaUkUiIKTgqTaoEnwlLO1SBnO RPric7/C6uigrRTS79US/3P4Lcbvu4wSy5fnsrfxqlF407Ph8D6AZyzNYStjJIG9JQmjqS/D dftViyzYAews9wnB1/fRv4MHGjLcihsxbvN8tvT97jrRk8NKTjEjZgzVw8bIKMyUAxrOVQID AQABo1QwUjARBglghkgBhvhCAQEEBAMCBaAwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQC MAAwHwYDVR0jBBgwFoAU/j5gnGuMD7DYM8bKxh5YsHE4teAwDQYJKoZIhvcNAQEEBQADgYEA Z42MrXC1NX3nIG/c3WsEPDhhrYKXJx5H41OnPaf6WO1mK8VdNBuxKl05zaFP+MmxoN/FP142 ZUb9lNM+2AnDGt70MIW6NKt9uXgW5Pc0NOaGTm12MnjVGMa0/ugDcIRR/eZ/7PVChF7nz5GI 79q9+YrQeicewj9qy5j4HIDcsFswggM5MIICoqADAgECAgEKMA0GCSqGSIb3DQEBBAUAMIHR MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv d24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9u IFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNOTgw OTE2MTc1NTM0WhcNMDAwOTE1MTc1NTM0WjCBuTELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRoYXd0ZSBDb25z dWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAxNzo1NTE2MDQG A1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5OC45LjE2MIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpeXU1NBfCALuByF9JL+ra44e6yAHAhWEa4/Q kyQfG53uaLK5LE/pk2cXEBceoflDQSO5MKp2l7vz5/2BwLUxi/amUCZU8pUo6xmkHpcesOK4 m8EEmjLQPAlsT+Q1T/B2vwATA09FCGDz/LTQkAGKEsmcun9S6iqTNTY8POQ1LwIDAQABozcw NTASBgNVHRMBAf8ECDAGAQH/AgEAMB8GA1UdIwQYMBaAFHJJwnM0xlX0C3ZygX539IfnxrIO MA0GCSqGSIb3DQEBBAUAA4GBACzHgh8BQz4Hj+5pXKlkgvjAlq2TK8ubUNdAmoHCuqZ2nTyV QNxVweFVgnmrCimm1QzhVyg+j/m71d8Nk1iqWy2LjzPk3VgVNXZyFSm9QvRakgt3X50n25ot ThuCBo7SjVa7ld7bDGUF3pWeAt1TF76+/GvDGiJ6FCthvcKfXnpaMYICHDCCAhgCAQEwgcEw gbkxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJh bnZpbGxlMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEpMCcGA1UECxMgVGhhd3RlIFBG IFJTQSBJSyAxOTk4LjkuMTYgMTc6NTUxNjA0BgNVBAMTLVRoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBSU0EgSXNzdWVyIDE5OTguOS4xNgIDAQ/VMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNOTkwODE0MjIwODE3WjAjBgkqhkiG 9w0BCQQxFgQUoF0vwqO89z8Vy/O1G4Y0SALldiEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG 9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcN AwICASgwDQYJKoZIhvcNAQEBBQAEgYBNo/9WqOli6nZf468D/txBOiUiRtZmIUqLrkyBoxQr 23dHRyCVX8zDc2FChtZ7MifauUA9wQz2xW+AQ/xuecR6rRVr8HcZux+DGNHKn7Zp2sX5QJ2T F9eVPGn7jRms28PnidrjUMoo6zCSd+IpEdRusFBPux8elsISMgys6lC9eg== --------------ms00CB884EF73ABC441C499DA5-- 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?37B5E8CD.EBEFACDB>