Hostnames
List members, Is t possible to have a server without a hostname? Thanks, -Michael Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Question about dns_lookup_realm and domain_realm
On Jun 27, 2008, at 11:51, Simo Sorce wrote: > Thanks, the explanation there makes a lot of sense, but reading > through > the lines it probably would not affect the original poster security, > because the "insecurity" of the TXT record is exploitable only in > case a > trusted realm is compromised (and the DNS spoofed at the same time). The "trusted realm" idea gets tossed around a lot, without a lot of specifics. Sometimes what is meant is, "a client in realm A can prove its identity to a server in realm B", and with multi-hop cross-realm authentication and (someday, we hope) something like PKCROSS, that doesn't have to imply any relationship directly between the two. With PKCROSS, all that's needed is KDCs to have certificates issued by trusted CAs. Sometimes what is meant is, "I know the administrators of realm B (or run it myself), and I put complete trust in anything they tell me, even if they're telling me something about my own users or servers". Kerberos cross-realm authentication is about the former. That said, if you don't exchange cross-realm keys with any outside realms, and disable PKCROSS if/when it gets implemented, you could have an isolated set of realms collectively considered part of your trusted computing base. >>> How is local configuration data trustworthy given that to resolve >>> names >>> to IPs we still rely on DNS ? Or do you also rely on /etc/hosts >>> for most >>> of the data ? >> If the host name resolves to a different IP address, the >> authentication >> will fail. > > Uhmm perhaps we are thinking of two different things, once you control > DNS you control both direct and reverse address resolution. The RFC says a Kerberos implementation shouldn't rely on DNS for determining the service principal name. That MIT's implementation does is a bug. (A long-standing one, one with implications as far as choices of names stored in keytabs, and changing it will involve some transition issues, as well as needing better support for handling multiple names for a server.) The name you attempt to *authenticate* to SHOULD be the name provided by the user, possibly transformed in some secure ways (e.g., add the local domain name, but do not look it up in DNS without DNSSEC). Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Question about dns_lookup_realm and domain_realm
Simo Sorce wrote: Uhmm perhaps we are thinking of two different things, once you control DNS you control both direct and reverse address resolution. Hence the reason that reverse DNS lookups are not to be used as per the Security Considerations of RFC 4120. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Question about dns_lookup_realm and domain_realm
On Fri, Jun 27, 2008 at 08:37:23AM -0400, Jeffrey Altman wrote: > > That's something my patch changes as it performs the DNS lookup first (when > > configured). > Which in turn would disable Kerberos referrals. Good to know. If referrals solve my problem, I'll set that up. > There is a serious need for the zero configuration solution for Kerberos > deployments. > Of course, DNS is insecure so relying on DNS to boot strap your > authentication system > is undesirable. That is not to say it has not been used but only > because there have > been no other choices. Amen. > For referrals to work the user must have already obtained a TGT. If you > are trying to decide > which identity a user should obtain a credential for based upon the host > that the user is going > to communicate with, that is not something that will be solved by > referrals. Understood. Thankfully that's not the issue here - the user already has a TGT. > To be honest, I don't think it will be solved by domain_realm mappings > whether stored > locally or in DNS. Based on what I know, I agree. Thanks, -- Jos Backus jos at catnook.com Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Question about dns_lookup_realm and domain_realm
On Fri, 2008-06-27 at 11:31 -0400, Jeffrey Altman wrote: > Simo Sorce wrote: > >> There are several issues here. First, DNS TXT records are known to be > >> insecure. > > > > Jeff, > > this statements is interesting, how are TXT records "insecure" ? > I will refer you to the security considerations section of the internet > draft. Note that > the insecurity is one reason that the TXT record portion of the draft > was not > added to RFC 4120 as the DNS SRV records portion was. > > http://tools.ietf.org/html/draft-ietf-krb-wg-krb-dns-locate-03 Thanks, the explanation there makes a lot of sense, but reading through the lines it probably would not affect the original poster security, because the "insecurity" of the TXT record is exploitable only in case a trusted realm is compromised (and the DNS spoofed at the same time). But it is a very interesting consideration nonetheless. > > How is local configuration data trustworthy given that to resolve names > > to IPs we still rely on DNS ? Or do you also rely on /etc/hosts for most > > of the data ? > If the host name resolves to a different IP address, the authentication > will fail. Uhmm perhaps we are thinking of two different things, once you control DNS you control both direct and reverse address resolution. > >> The safe way to add DNS TXT records back into the equation would be to > >> add the DNS TXT > >> lookup after the referrals request fails. > > > > Do we have information on which clients support referrals ? > > And are they implemented in MIT KDC (and how) ? > > > Heimdal, MIT, and Microsoft support referrals as implemented in Windows > Active Directory. > The IETF Kerberos working group is still working on an RFC for referrals. > > http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kerberos-referrals-10.txt Thanks a lot, lots of very useful info here. Simo. -- Simo Sorce * Red Hat, Inc * New York Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Question about dns_lookup_realm and domain_realm
Simo Sorce wrote: There are several issues here. First, DNS TXT records are known to be insecure. Jeff, this statements is interesting, how are TXT records "insecure" ? I will refer you to the security considerations section of the internet draft. Note that the insecurity is one reason that the TXT record portion of the draft was not added to RFC 4120 as the DNS SRV records portion was. http://tools.ietf.org/html/draft-ietf-krb-wg-krb-dns-locate-03 Turning them on for use in realm resolution provides for convenience but at the risk that your clients can be redirected to a realm that you do not control. You can do the same with DNS poisoning, if you do not trust DNS any name resolution becomes "insecure". Isn't "validation" all about verifying the KDC is one we can really trust by using a trusted secret ? If the host name resolves to a different IP address, the authentication will fail. Second, any domain_realm mapping for your domain .foo.com is going to override the use of DNS lookups. That is because local configuration data is considered to be trustworthy whereas DNS lookups are not. How is local configuration data trustworthy given that to resolve names to IPs we still rely on DNS ? Or do you also rely on /etc/hosts for most of the data ? If the host name resolves to a different IP address, the authentication will fail. The safe way to add DNS TXT records back into the equation would be to add the DNS TXT lookup after the referrals request fails. Do we have information on which clients support referrals ? And are they implemented in MIT KDC (and how) ? Heimdal, MIT, and Microsoft support referrals as implemented in Windows Active Directory. The IETF Kerberos working group is still working on an RFC for referrals. http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kerberos-referrals-10.txt Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Question about dns_lookup_realm and domain_realm
On Jun 27, 2008, at 11:17, Simo Sorce wrote: > this statements is interesting, how are TXT records "insecure" ? If a forged TXT RR is received, the client may be told the server is in a different realm. That realm may have been compromised by an attacker, and cross-realm authentication to it may be possible (especially if and when we get something PKINIT-like deployed). So the client can "successfully" authenticate to host/[EMAIL PROTECTED] , and never know that that's not the principal it should be authenticating to for server.foo.com. > Isn't "validation" all about verifying the KDC is one we can really > trust by using a trusted secret ? Cross-realm authentication and the possibility of compromised "neighbor" realms makes it much more complicated. > How is local configuration data trustworthy given that to resolve > names > to IPs we still rely on DNS ? Trusting address records from DNS, but not trusting DNS at all for authentication purposes, would mean the attacker could get the client to connect to server.black-hats.tld, but it would try authenticating to the originally intended service principal; since the black hats don't have the service key, it would fail, and the client should disconnect. It's a denial of service, but not a transparent spoofing of the service. > Do we have information on which clients support referrals ? Current Microsoft and MIT clients do, I wouldn't be surprised if Heimdal does as well. > And are they implemented in MIT KDC (and how) ? Not yet. A basic implementation (using the domain_realm mapping from the KDC's config files) is currently on my plate. Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Question about dns_lookup_realm and domain_realm
On Fri, 2008-06-27 at 01:57 -0400, Jeffrey Altman wrote: > Jos Backus wrote: > > On Fri, Jun 27, 2008 at 12:52:49AM -0400, Jeffrey Altman wrote: > >> This behavior was most likely broken when the referrals code was added. > > > > So it's a regression. Until this is fixed properly (which I don't claim my > > patch does :-) ) I'm possibly need of a workaround. Do you see anything > > wrong > > with the patch as such? > There are several issues here. First, DNS TXT records are known to be > insecure. Jeff, this statements is interesting, how are TXT records "insecure" ? > Turning > them on for use in realm resolution provides for convenience but at the > risk that your clients > can be redirected to a realm that you do not control. You can do the same with DNS poisoning, if you do not trust DNS any name resolution becomes "insecure". Isn't "validation" all about verifying the KDC is one we can really trust by using a trusted secret ? > Second, any domain_realm mapping for your domain .foo.com is going to > override the use > of DNS lookups. That is because local configuration data is considered > to be trustworthy > whereas DNS lookups are not. How is local configuration data trustworthy given that to resolve names to IPs we still rely on DNS ? Or do you also rely on /etc/hosts for most of the data ? > The safe way to add DNS TXT records back into the equation would be to > add the DNS TXT > lookup after the referrals request fails. Do we have information on which clients support referrals ? And are they implemented in MIT KDC (and how) ? thanks, Simo. -- Simo Sorce * Red Hat, Inc * New York Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: guidance
Are you aware that there are two different flavors of pkinit? There is the original protocol deployed by Microsoft in Windows 2000 (sometimes referred to as the "Draft 9 version" because it was basically the version defined by draft 9 of the RFC) and then the finalized RFC version (which was something like draft number 24). Do you know which version your client uses? The code in MIT 1.6.3 supports both versions of the protocol. It would be up to your client to make sure that it correctly identifies the protocol version it is using. (There are different preauth padata types for each version.) #define KRB5_PADATA_PK_AS_REQ_OLD 14 /* PKINIT */ #define KRB5_PADATA_PK_AS_REP_OLD 15 /* PKINIT */ #define KRB5_PADATA_PK_AS_REQ 16 /* PKINIT */ #define KRB5_PADATA_PK_AS_REP 17 /* PKINIT */ Beyond that, you would probably need to compile the KDC code to support debugging and trace through to find the portion of the client's request that the server code does not like. You might start looking at the code in src/lib/krb5/asn.1/asn1_k_decode.c. K.C. On Fri, Jun 27, 2008 at 8:42 AM, naveen.bn <[EMAIL PROTECTED]> wrote: > > Hi Kevin, > > I am facing a problem and would like to get suggestion from you regarding it > . > > My seniors had come up with a kerberos client which took the reference from > krb5-1.2.2, which was with out PKINIT support and they > had added the PKINIT support for it. I have no contact with them , I have > no idea what server they had used. > But, now that the krb5-1.6.3 supports PKINIT, I am trying to use it as > Server . My client works without PKINIT, but with PKINIT > support the server (krb5-1.6.3) is not able to decode AS_REQ packet and > the kdc log says > preauth (pkinit) verify failure: ASN.1 identifier doesn't match expected > value. > > I tested the AS_REQ with the tool dumpasn1.c, I found no problem in pkinit > asn1 dump. > > Kindly help me in solving this problem > Thank you > > naveen > > > > > > > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely > for the use of the addressee(s). If you are not the intended recipient, > please notify the sender by e-mail and delete the original message.Global > Edge Software Ltd has taken every reasonable precaution to minimize this > risk, but is not liable for any damage you may sustain as a result of any > virus in this e-mail. You should carry out your own virus checks before > opening the e-mail or attachment. Global Edge Software Ltd reserves the > right to monitor and review the content of all messages sent to or from this > e-mail address > > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely > for the use of the addressee(s). If you are not the intended recipient, > please notify the sender by e-mail and delete the original message.Global > Edge Software Ltd has taken every reasonable precaution to minimize this > risk, but is not liable for any damage you may sustain as a result of any > virus in this e-mail. You should carry out your own virus checks before > opening the e-mail or attachment. Global Edge Software Ltd reserves the > right to monitor and review the content of all messages sent to or from this > e-mail address > > Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
guidance
Hi Kevin, I am facing a problem and would like to get suggestion from you regarding it . My seniors had come up with a kerberos client which took the reference from krb5-1.2.2, which was with out PKINIT support and they had added the PKINIT support for it. I have no contact with them , I have no idea what server they had used. But, now that the krb5-1.6.3 supports PKINIT, I am trying to use it as Server . My client works without PKINIT, but with PKINIT support the server (krb5-1.6.3) is not able to decode AS_REQ packet and the kdc log says preauth (pkinit) verify failure: ASN.1 identifier doesn't match expected value. I tested the AS_REQ with the tool dumpasn1.c, I found no problem in pkinit asn1 dump. Kindly help me in solving this problem Thank you naveen This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message.Global Edge Software Ltd has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Global Edge Software Ltd reserves the right to monitor and review the content of all messages sent to or from this e-mail address Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Question about dns_lookup_realm and domain_realm
Jos Backus wrote: On Fri, Jun 27, 2008 at 01:57:37AM -0400, Jeffrey Altman wrote: There are several issues here. First, DNS TXT records are known to be insecure. Turning them on for use in realm resolution provides for convenience but at the risk that your clients can be redirected to a realm that you do not control. Understood. Second, any domain_realm mapping for your domain .foo.com is going to override the use of DNS lookups. That is because local configuration data is considered to be trustworthy whereas DNS lookups are not. That's something my patch changes as it performs the DNS lookup first (when configured). Which in turn would disable Kerberos referrals. In the case of two realms, PROD.FOO.COM and DEV.FOO.COM some of your hosts are in one and some are in the other. By default you want PROD.FOO.COM to be used. However, for specific hosts you want DEV.FOO.COM.Using the config file you would specify [domain_realm] devhost1.foo.com = DEV.FOO.COM .foo.com = PROD.FOO.COM Yup, tried that, works, but doesn't scale well. There is a serious need for the zero configuration solution for Kerberos deployments. Of course, DNS is insecure so relying on DNS to boot strap your authentication system is undesirable. That is not to say it has not been used but only because there have been no other choices. If you want to rely on DNS TXT records you have to make sure that there are no mappings in the config file. Then you would create records for _kerberos.devhost1.foo.com IN TXT DEV.FOO.COM _kerberos.foo.com IN TXT PROD.FOO.COM Okay. We have the former (obviously) but not the latter. I can add that. Because DNS TXT records are insecure and there is a need to be able to provide for centralized configuration data Microsoft created the Kerberos referrals mechanism. Using referrals a client asks the KDC belonging to the TGT realm for a referral to the correct realm for the desired service principal. Referrals are used whenever there is not a local [domain_realm] mapping. So this implies two-way trust and communication, yes? I wonder if this will require network/ACL changes. For referrals to work the user must have already obtained a TGT. If you are trying to decide which identity a user should obtain a credential for based upon the host that the user is going to communicate with, that is not something that will be solved by referrals. To be honest, I don't think it will be solved by domain_realm mappings whether stored locally or in DNS. The safe way to add DNS TXT records back into the equation would be to add the DNS TXT lookup after the referrals request fails. ISTR that's where krb5_get_fallback_host_realm() is called, from a comment in the code. Now it's clear why although I still don't quite grok the referral mechanism. Time to study the documentation. Thanks for the critique and helpful information, Jeffrey. No problem. smime.p7s Description: S/MIME Cryptographic Signature Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
