Re: Insisting on DNSSEC (was: tickets with wrong DNS)
Hi, > DNSSEC is an awesome idea for clients, but has really nothing to do with > checking if AS requests should succeed or not. > When it comes to AS requests, from the KDC POV all that really matters is > whether you have a valid key or not. When using pre-authentication (which I haven’t studied extensively in all lits variations so just tell me if I’m ignorant) I prefer to send it to the proper KDC, and that is one place where DNSSEC can help. Another place where it could be helpful is for cross-realm authentication, where it is preferred to skip by any men in the middle; but now I’m (also) thinking ahead of a dream that I have, where Kerberos realms could have a (pubkey/DNSSEC-based) manner of cross-realm authentication with new and unknown parties. > DNSSEC might be used to perform canonicalization on the KDC side, so it may > be relevant to resolve a TGS request if the principal is not found as > transmitted by the client and the client requests canonicalization, but > that's a different story, and once again does not really involve the actual > IP addresses any of the resolved address points to. This is indeed another part that I have in mind, and for now my chief point of interest. A KDC should not rely on flaky DNS data if it can help it. And, depending on operator paranoia, it could be useful to enforce DNSSEC for anything deemed acceptable for the KDC. Thanks, -Rick Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Insisting on DNSSEC (was: tickets with wrong DNS)
- Original Message - > Hi, > > > The KDC has no way of knowing if DNS is correct or wrong, > > It could of course use a DNSSEC-aware resolver. > > > nor would it > > trust the DNS > > That is a setting with MIT krb5, and an admin could feel safe to enable it > after setting up DNSSEC. > > > even if it were able to ask a sensible question out of it. > > I’ve been thinking along these lines, and would prefer to be able to install > a secure name resolver on my KDC, and making it *require* DNSSEC. This > could also help to trust remote, unknown zones. I wrote it down on > > http://rickywiki.vanrein.org/doku.php?id=insisting-on-dnssec > > It seems that I am the only one who sees a case for *insisting* on DNSSEC, or > do others on this list agree there is a need? DNSSEC is an awesome idea for clients, but has really nothing to do with checking if AS requests should succeed or not. When it comes to AS requests, from the KDC POV all that really matters is whether you have a valid key or not. DNSSEC might be used to perform canonicalization on the KDC side, so it may be relevant to resolve a TGS request if the principal is not found as transmitted by the client and the client requests canonicalization, but that's a different story, and once again does not really involve the actual IP addresses any of the resolved address points to. HTH, Simo. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Insisting on DNSSEC (was: tickets with wrong DNS)
Hi, > The KDC has no way of knowing if DNS is correct or wrong, It could of course use a DNSSEC-aware resolver. > nor would it > trust the DNS That is a setting with MIT krb5, and an admin could feel safe to enable it after setting up DNSSEC. > even if it were able to ask a sensible question out of it. I’ve been thinking along these lines, and would prefer to be able to install a secure name resolver on my KDC, and making it *require* DNSSEC. This could also help to trust remote, unknown zones. I wrote it down on http://rickywiki.vanrein.org/doku.php?id=insisting-on-dnssec It seems that I am the only one who sees a case for *insisting* on DNSSEC, or do others on this list agree there is a need? Cheers, -Rick Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
