[38433] in Kerberos
Re: Kerberos n00b question.
daemon@ATHENA.MIT.EDU (Grant Taylor)
Tue Jan 8 22:15:55 2019
To: kerberos@mit.edu
From: Grant Taylor <gtaylor@tnetconsulting.net>
Message-ID: <ab038516-6559-3773-4435-a2ffdba2a584@spamtrap.tnetconsulting.net>
Date: Tue, 8 Jan 2019 20:15:46 -0700
MIME-Version: 1.0
In-Reply-To: <jlgy37uy76f.fsf@redhat.com>
Content-Type: multipart/mixed; boundary="===============6237633860735858333=="
Errors-To: kerberos-bounces@mit.edu
This is a cryptographically signed message in MIME format.
--===============6237633860735858333==
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
micalg=sha-256; boundary="------------ms050206060707050800080501"
This is a cryptographically signed message in MIME format.
--------------ms050206060707050800080501
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
On 1/8/19 6:02 PM, Robbie Harwood wrote:
> It still reduces to the security of a password (the one locking the=20
> random key).
I agree that the passwords are the weakest link. But I thought (hoped)=20
that it would bolster the strength of the (derived) key that Kerberos use=
s.
> But as Russ points out, you may be interested in PKINIT if users choosi=
ng=20
> strong passwords is a serious worry.
I am interested and will be reading about PKINIT.
I read <~> skimmed RFC 6113 earlier today. - I feel like I'm trying to =
swim with cloths on. High level concepts make some sense. But I'm=20
still getting enough bearings to be able to make more sense of things=20
without getting too mired down in details. - I'm looking for a=20
conceptual overview / understanding of what things do at the moment.
It seems as if FAST provides an extension framework that a number of=20
things can use, including some options to provide encrypted=20
pre-authentication connections.
I think that PKINIT is another method to derive some of the values that=20
FAST can use.
> Also! 2FA will mitigate this concern somewhat as well.
I was wondering about 2nd factor authentication. I have a YubiKey=20
that's waiting for my attention.
Would I be correct in assuming that (from a Kerberos point of view) the=20
1st and 2nd factors are used during the kinit process? Meaning that all =
of the SSO functions still work unimpeded?
I think that it's more that I want to set Kerberos up using best=20
practices as I start using it. I don't want to start something new=20
(like build a website) and then find out that I made a bone headed=20
mistake (like not salting hashed passwords).
Everything I'm doing, Kerberos included, is functionally for me, myself, =
and I. I'm still trying to decide which one has the worst security postu=
re.
> krb5 is prepared to hand off to a RADIUS responder for OTP
I've been meaning to read about RADIUS as I know that it's an integral=20
component of 802.1X which I want to set up when I find a few spare=20
Round-Tuits.
> (freeIPA uses this, which I know you're not interested in but is=20
> meaningful as a PoC);
There's nothing at all wrong with playing with the boxed Lego set to=20
learn how things are done. Once I've done that, I tear all the pieces=20
apart and build my own thing, or add on to my other things.
> you can then use something like freeOTP or a physical 2fa token for=20
> acquiring additional credentials.
*nod*
> You don't have to recreate them, but yes, it's a good idea to set=20
> +requires_preauth. Setting -allow_svr will I believe block the use of =
> U2U and make kvno on user principals no longer work, but this may be=20
> acceptable to you
I need to do some more reading on what user-to-user and kvno are to know =
if I care about them.
The main thing that I care about that I'm not sure if it's impacted or=20
not is .k5login / .k5users. - I don't think that would be impacted,=20
but I don't know enough to confidently say one way or the other.
The little bit of reading that I just did on key version number (kvno)=20
sounds unrelated to servers / services (what I think of with allow_svr). =
I need to do more reading.
On the surface, I think I'd like to keep kvno functional.
Would -allow_svr have any impact on protocol translation? (I think=20
that's the term.) I.e. when a non-Kerberos aware client logs into IMAPS =
with username & password and the daemon translates / gateways / bridges=20
into Kerberos on the client's behalf? (I saw something about that in=20
one of the first three videos I mentioned in a previous message.)
> Apologies. I consider Kerberos (with preauth and strong passwords)=20
> safe for internet use, as I imagine the rest of us on here do as well.
:-)
Good. I'm starting to get similar impression as I read more things. I=20
still think I want to keep client <-> KDC on the same LAN. But I'm=20
getting more and more comfortable with using Kerberos, via GSSAPI, with=20
services across the Internet.
> Kerberos exchanges are not reliant on additional layers of encapsulatio=
n=20
> for security. Russ went into more detail on this I think for SSH.=20
> But it's all encrypted with pre-shared knowledge, be it passwords or=20
> keytabs or certs (or things derived from those) - except for things tha=
t=20
> don't need to be kept secret, like usernames.
ACK
> Yes. Provisioning is always the hard part in any cryptosystem :)
>=20
> It's possible to, on the server, kinit and acquire the keytab that way.=
=20
> But if you're SSHing in already, there isn't really an advantage to tha=
t.
Agreed.
I do think that would expose the Kerberos client (the server in this=20
context) to KDC exchange to the Internet. Which it sounds like this is=20
reasonably secure enough.
I was not aware that I could get the keytab via kinit. I had used=20
kadmin on clients (in the LAN) to get it. - This is why I ask questions=
=2E
> It's not a Linux distro - it's a tool that can be run on man distros - =
> but yes.
Thank you for the clarification.
> Totally fine! I also appreciate the need to tinker - but I've also set=
=20
> up enough realms to be tired of trying to figure out what I did wrong=20
> with LDAP this time :)
LOL
Fair enough.
I'm not there (yet). And I still want to graft the new Kerberos colored =
Lego bricks into my existing creations. (For better or worse.)
> Thanks,
You're welcome. But it is me that needs to say thank you. You and Russ =
have given me a lot to read and think about. I appreciate that. :-)
--=20
Grant. . . .
unix || die
--------------ms050206060707050800080501
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
Cy4wggVAMIIEKKADAgECAhEA01fiRe1k2R6LEQCcImIMYTANBgkqhkiG9w0BAQsFADCBlzEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs
Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg
Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgxMTE4MDAw
MDAwWhcNMTkxMTE4MjM1OTU5WjArMSkwJwYJKoZIhvcNAQkBFhpndGF5bG9yQHRuZXRjb25z
dWx0aW5nLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANgOhvncDgc4KAlD
+pyhFpw6wCfeERlSOAXowjdTjlOR2zcIgzL0TM9A+hkSv2wsVh6fn6VvHGxKrLemReiGd7fQ
15Y9J/pxKOmShkw9DDtFsa18ozydp95X2IuzY8Z2JukxouqrfpSH4fOrrHLkOgvlFG4xaQHW
0KB8xUP5DFWyyZM5QCdq278GSJ5pUd+B6qmzwHESNF6syyvgLppXkFatLTz8pWf6eEngDA0Y
3fQ3Q2gnbgpryRhVQMa1GjQJ7LDroUGQhX2zBWePW+sShiTwo8jADYKsbgSGtvZ/42A8zxyg
s9YZMHQoCeeuLNuX/MBp9rCTl5nlzP3jGWQTC5ECAwEAAaOCAfAwggHsMB8GA1UdIwQYMBaA
FIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBQg2PeEKxHWd4FaHe0T+gqAOWkC1jAO
BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB
BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEB
MCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoGA1UdHwRT
MFEwT6BNoEuGSWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhl
bnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEF
BQcwAoZJaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGlj
YXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29t
b2RvY2EuY29tMCUGA1UdEQQeMByBGmd0YXlsb3JAdG5ldGNvbnN1bHRpbmcubmV0MA0GCSqG
SIb3DQEBCwUAA4IBAQCPxlHHG57PA5GUYlQuC8VHB7TcMQeEJKnB/S+bamyrck4vpIEaF9rG
EM+OnAQsJzSkSVHD2707jxh1ng0jrsH2+F9qNGTpCksXo0fMqm4tf28Ag092+CZ5sfdjVZ4E
ELG4xNhFZF9/aFaAY7RIeJ89Vvn6s6BnKsaAPjVB/sO+5gIm0BIeoVauq71ue6jS7o2Jn94o
BuAhjuh34gk/Wxzcku96MLmEwCY63GWWKVRYbqrDhqROmnQPdyrDYrU8uD0vb4SAdpSKfRqO
DrerlQgX3euyYqcnVJSA8Ec+NdiJrGKXW76C7DrTi7IxDgjIHL+DPyFgtj+p6wYOEkYJwKtp
MIIF5jCCA86gAwIBAgIQapvhODv/K2ufAdXZuKdSVjANBgkqhkiG9w0BAQwFADCBhTELMAkG
A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y
ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxKzApBgNVBAMTIkNPTU9ETyBSU0EgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTMwMTEwMDAwMDAwWhcNMjgwMTA5MjM1OTU5WjCB
lzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMH
U2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBS
U0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+s55XrCh2dUAWxzgDmNPGGHYhUPMleQtMtaDRfTpY
PpynMS6n9jR22YRq2tA9NEjk6vW7rN/5sYFLIP1of3l0NKZ6fLWfF2VgJ5cijKYy/qlAckY1
wgOkUMgzKlWlVJGyK+UlNEQ1/5ErCsHq9x9aU/x1KwTdF/LCrT03Rl/FwFrf1XTCwa2QZYL5
5AqLPikFlgqOtzk06kb2qvGlnHJvijjI03BOrNpo+kZGpcHsgyO1/u1OZTaOo8wvEU17VVeP
1cHWse9tGKTDyUGg2hJZjrqck39UIm/nKbpDSZ0JsMoIw/JtOOg0JC56VzQgBo7ictReTQE5
LFLG3yQK+xS1AgMBAAGjggE8MIIBODAfBgNVHSMEGDAWgBS7r34CPfqm8TyEjq3uOJjs2TIy
1DAdBgNVHQ4EFgQUgq9sjPjF/pZhfOgfPStxSF7Ei8AwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud
EwEB/wQIMAYBAf8CAQAwEQYDVR0gBAowCDAGBgRVHSAAMEwGA1UdHwRFMEMwQaA/oD2GO2h0
dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNlcnRpZmljYXRpb25BdXRob3JpdHku
Y3JsMHEGCCsGAQUFBwEBBGUwYzA7BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5j
b20vQ09NT0RPUlNBQWRkVHJ1c3RDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNv
bW9kb2NhLmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAeFyygSg0TzzuX1bOn5dW7I+iaxf28/ZJ
CAbU2C81zd9A/tNx4+jsQgwRGiHjZrAYayZrrm78hOx7aEpkfNPQIHGG6Fvq3EzWf/Lvx7/h
k6zSPwIal9v5IkDcZoFD7f3iT7PdkHJY9B51csvU50rxpEg1OyOT8fk2zvvPBuM4qQNqbGWl
nhMpIMwpWZT89RY0wpJO+2V6eXEGGHsROs3njeP9DqqqAJaBa4wBeKOdGCWn1/Jp2oY6dyNm
NppI4ZNMUH4Tam85S1j6E95u4+1Nuru84OrMIzqvISE2HN/56ebTOWlcrurffade2022O/tU
U1gb4jfWCcyvB8czm12FgX/y/lRjmDbEA08QJNB2729Y+io1IYO3ztveBdvUCIYZojTq/OCR
6MvnzS6X72HP0PRLRTiOSEmIDsS5N5w/8IW1Hva5hEFy6fDAfd9yI+O+IMMAj1KcL/Zo9jzJ
16HO5m60ttl1Enk8MQkz/W3JlHaeI5iKFn4UJu1/cP2YHXYPiWf2JyBzsLBrGk1II+3yL8ao
rYew6CQvdVifC3HtwlSam9V1niiCfOBe2C12TdKGu05LWIA3ZkFcWJGaNXOZ6Ggyh/TqvXG5
v7zmEVDNXFnHn9tFpMpOUvxhcsjycBtH0dZ0WrNw6gH+HF8TIhCnH3+zzWuDN0Rk6h9KVkfK
ehIxggQ4MIIENAIBATCBrTCBlzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFu
Y2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQx
PTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg
RW1haWwgQ0ECEQDTV+JF7WTZHosRAJwiYgxhMA0GCWCGSAFlAwQCAQUAoIICWzAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTAxMDkwMzE1NDZaMC8GCSqG
SIb3DQEJBDEiBCDMAL4haSaKxxiMtMruwxe9+FX0ldrT7PDsP36W2APNczBsBgkqhkiG9w0B
CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN
AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG+BgkrBgEE
AYI3EAQxgbAwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0
ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYD
VQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls
IENBAhEA01fiRe1k2R6LEQCcImIMYTCBwAYLKoZIhvcNAQkQAgsxgbCgga0wgZcxCzAJBgNV
BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx
GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVu
dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA01fiRe1k2R6LEQCcImIM
YTANBgkqhkiG9w0BAQEFAASCAQBEDOj5o54ghb44icahcq7YvnBqs23/DHAosfINNhQCBoMI
Kpm9ijDw9NSHSBLwMQOSPem1nq7tKURWDNlkm7qy3JPqKmtpNo+ImBux4I0cGC7tL95oGjqe
o/xNi4gxQte8xlD3pG8na8QXAd94c7OzV+MK5DqeBNpvP+4noop2xpkk2PcefFrjHMmE4ndV
r87via+ispCHZiAnQoSUL282E5AtAuFUzVl4RgoaHjPtCQDO0KECQV94scge1s1bqx3fr7pp
SMPYVZMjI8kEykyZC9jjp5mUhD9lKLuzqd1EzZ5NO8FdEYGZbgC/9WQduKxF1LqnkM9e0kGn
j6vuVNd+AAAAAAAA
--------------ms050206060707050800080501--
--===============6237633860735858333==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
--===============6237633860735858333==--
