Re: [Freeipa-devel] Off Topic, was: [PATCH 0017] Add OTP support to ipalib CLI
On 09/13/2013 06:06 PM, Henry B. Hotz wrote: On Sep 13, 2013, at 11:38 AM, Dmitri Pal d...@redhat.com wrote: , ipatokenotpalgorithm Uses default TOTP we do not support more for now. In future it will be a global policy I assume. This is just me, like the sig says. I would advocate for HOTP, with a bunch of special processing for token counter regression. If the token seed and current counter are stolen by a bad guy, and actually used, then at some point the bad guy or the real user are going to attempt an authentication using a value that's old. This presents an opportunity to detect that the theft took place. I regard this as a real, useful security feature which is not possible with time-based tokens, provided the verification infrastructure is set up to do the detection, and to take some action when the detection occurs. If the theft is done by a smart-enough adversary, there may be nothing to prevent them from resynchronizing the legitimate copy of the soft-token when they use it, but it still seems like a worthwhile capability. It would detect the most obvious token-theft scenarios. Obviously, this is out-of-scope for any of your current efforts, but I wanted to throw it in the mix for possible future work. Count creates an overhead in the replicated environment. Effectively you need to replicate count on every authentication, this is a big cost. While it is more secure for the case you suggest it does not seem to be a good enough justification for the replication overhead. If stolen the chance that it will be used some tine later is really slim. It most likely will be used right away so the old code detection will be irrelevant. But we anticipate that there will be cases when HOTP will be needed, so we do not preclude implementing it in future but on the other hand do not see it as an immediate goal either. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. henry.b.h...@jpl.nasa.gov, or hbh...@oxy.edu -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Improve FreeIPA usability in cloud environments
On 09/14/2013 01:27 PM, Simo Sorce wrote: On Fri, 2013-09-13 at 14:26 -0400, Dmitri Pal wrote: On 09/13/2013 09:08 AM, Simo Sorce wrote: On Fri, 2013-09-13 at 10:26 +0200, Petr Spacek wrote: Hello list, FreeIPA deployments in cloud environments do not work very well because 'clouds' break some assumptions we made during FreeIPA's design. We should fix it somehow :-) === Problems === - A machine has two host names in DNS: -- The first name is internal to the cloud and resolvable only from inside of the cloud. --- This name should be used for communication inside cloud. --- E.g. 'ipa.cust1.cloud.' --- Internal name is mapped to internal IP address, see below. -- The second name is external to the cloud and should be used for communication between the Internet and cloud. --- E.g. 'ipa.example.com.' --- External name maps to external IP address, see below. - A machine has two IP addresses: -- Internal, private IP address configured at the machine's interface --- Typically the only IP address known to the machine. --- E.g. 192.0.2.22 --- IP address can change dynamically, at least after a machine reboot. -- External, public IP address: --- Typically mapped to internal address at cloud boundary (NAT). --- E.g. 203.0.113.113 --- IP address can change dynamically, at least after a machine reboot. Related tickets: https://fedorahosted.org/freeipa/ticket/2648 https://fedorahosted.org/freeipa/ticket/2715 The natural request is to add support for DNS views/split horizon DNS into FreeIPA, so different names and IP addresses can be served to clients inside and outside of the cloud. Is it enough? What else should we change to make FreeIPA reliable in clouds? I do not understand what's the use of views in this case. Views are used when you want to assign different IP addresses to the same name depending on where the query comes from. But here we have different names pointing to different addresses and the machine actually know nothing about the external name/IP. So what is the point of a view here ? From the FreeIPA pov, if you use it for infrastructure you should just care about internal names. For the rare case where you want to have some client use the external name to access a machine then what we need to do is to make it easy (it is possible but not exposed now) to assign aliases to hosts so that you get an alias for each host/ and other service principals in the kerberos database and you get alternate names in the x509 certs. But I still do not see any issues with DNS, except for the fact that the network manager service of the cloud provider needs to be able to maintain the DNS records according to how it assigns IPs to names. What are use cases? Do we want to support clients *outside* of the cloud connecting to FreeIPA servers *inside* of the cloud? I think we should give the option, see above. What about PKI certificates? Should we put two names to each certificate? What we should do after host name change? (I do not have enough information when the host name changes.) A change in host name will require a new certificate. But if the name is stable then we just need to populate certs with aliases What about Kerberos? How it will play with host name change? How should we handle the fact that internal and external names are different? Should we use some sort of referral mechanism? Uhmm a referral may also work in future, but we could simply uses aliases, not all applications may work properly (some insist on a specific name, but a lot of apps these days can be configured to use just the service name and then accept tickets as long as they can be decrypted (key is the same). Cloud users, please speak now :-) Opinions are more than welcome! Indeed, if you see any wrong assumption in here, it would be *really* nice to have a heads up. Simo. Do we have an RFE about aliases? We should have one for kerberos, the LDAP/kdb part is already capable of supporting aliases. Do we need several? One for Kerberos part another for PKI? May be more than that? For client checks may be? We should have a separate one for x509 certs, yes. Simo. Please open. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [RFC] Improve FreeIPA usability in cloud environments
On Fri, Sep 13, 2013 at 4:26 AM, Petr Spacek pspa...@redhat.com wrote: Hello list, Hey FreeIPA deployments in cloud environments do not work very well because 'clouds' break some assumptions we made during FreeIPA's design. We should fix it somehow :-) Agreed ! === Problems === - A machine has two host names in DNS: -- The first name is internal to the cloud and resolvable only from inside of the cloud. --- This name should be used for communication inside cloud. --- E.g. 'ipa.cust1.cloud.' --- Internal name is mapped to internal IP address, see below. -- The second name is external to the cloud and should be used for communication between the Internet and cloud. --- E.g. 'ipa.example.com.' --- External name maps to external IP address, see below. - A machine has two IP addresses: -- Internal, private IP address configured at the machine's interface --- Typically the only IP address known to the machine. --- E.g. 192.0.2.22 --- IP address can change dynamically, at least after a machine reboot. In my situation, the IP's are always constant. -- External, public IP address: --- Typically mapped to internal address at cloud boundary (NAT). --- E.g. 203.0.113.113 --- IP address can change dynamically, at least after a machine reboot. Related tickets: https://fedorahosted.org/freeipa/ticket/2648 https://fedorahosted.org/freeipa/ticket/2715 The natural request is to add support for DNS views/split horizon DNS into FreeIPA, so different names and IP addresses can be served to clients inside and outside of the cloud. I've asked about split view DNS support before. It would be extremely valuable! Is it enough? What else should we change to make FreeIPA reliable in clouds? What are use cases? As described above, my particular use case is one machine with one consistent hostname, but with multiple IP addresses. Internally the VM sees itself as say 10.10.10.1, but externally it might have one or more different addresses that are used to NAT directly to it for example. Do we want to support clients *outside* of the cloud connecting to FreeIPA servers *inside* of the cloud? What about PKI certificates? Should we put two names to each certificate? What we should do after host name change? (I do not have enough information when the host name changes.) I never have any issues about different host names. All are consistent. What about Kerberos? How it will play with host name change? How should we handle the fact that internal and external names are different? Should we use some sort of referral mechanism? Cloud users, please speak now :-) Opinions are more than welcome! Some comments are given above. Please keep me in the loop. Once this is cooking, I'd love to add puppet-ipa support to match. https://github.com/purpleidea/puppet-ipa I'm happy to answer any questions you have. -- Petr^2 Spacek Thanks, James ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
