William, in a lot of ways I buy the proposal below, but there's a big
question unanswered: can you share the certificates used for wanboot
with your proposed mechanism when we go to a secure solution? That is a
requirement in order to go down this path.
Dave
On 10/ 6/10 09:55 AM, William Schumann wrote:
On 10/ 4/10 09:30 PM, Dave Miner wrote:
On 10/ 4/10 02:47 PM, William Schumann wrote:
On 10/ 1/10 05:28 PM, Dave Miner wrote:
...
Delivering them simultaneously is perfectly fine, and as you can
gather, I think preferable. My point of view is that wanboot-cgi
has a quite suitable method already for delivering a bundle of
content and would like to see that leveraged, rather than inventing
yet another mechanism that is specific to system configuration.
Consider the simplicity of MIME as a way to bundle content.
...
I'm well aware that wanboot uses MIME to encode its entire message. I
am not yet convinced that we shouldn't just be using its
already-implemented capabilities to return these, however.
Missing from wanboot-cgi:
- means of adding more files to wanbootfs
The proposal mentions an approach to adding a flexible means by which
files could be added to wanbootfs, through naming a new entry in
wanboot.conf, specifying a script to locate the profiles and an output
directory.
Missing from wanboot (client-side standalone program):
1) x86 support
2) gathering and sending AI client criteria (IP, hostname, memory size,
MAC address, cpu, platform) required for locating profiles
wanboot-cgi sends the wanbootfs in a custom format. This is a relatively
small problem, until security is considered: the code to authenticate
and guarantee integrity processes wanbootfs byte-by-byte. An x86 wanboot
client would be a user-mode application that would be different from the
SPARC wanboot, which writes the wanbootfs into a ramdisk, doing HMAC
calculations on each byte.
Adding support for standalone wanboot to collect and send AI client
criteria would be more difficult with Solaris missing. Instead of
attempting to gather criteria standalone, I think that a
platform-independent user-mode version of wanboot that supplies the
criteria to wanboot-cgi that is called about the same time in the boot
process that the AI manifest is fetched (possibly also supplying the AI
manifest) would be preferable.
Now, wanboot/wanboot-cgi has a big advantage in that it securely
delivers the SSL certificates to the AI client. For this, the user
provides a HMAC and a key, totaling about 50 characters. An x86 solution
(or for a SPARC box that does not support wanboot in its OBP) would need
some way to get the SSL certificates securely, and porting the wanbootfs
fetch to a user-mode application would accomplish this. (Alternate
solutions for the client obtaining the security certificates include
certificate server, providing certificates on install media, reading
certificates from removable media, copying certificates from locally
secure source.)
Considering the work a Python-based server solution would be responsible
for (disregarding what is common to both approaches):
- client authentication referring to certificates on the AI server in a
fashion compatible with certificates in /etc/netboot
- some simple MIME encoding
The client side would also be a very simple script:
- leveraging Python modules httplib and urllib to form and issue the
HTTP POST
- calling existing Python AI code to fetch client criteria
- leveraging the Python email module to unpack the profiles, saving them
into the new /etc/svc/profile.
On the subject of secure network booting from the x86 platform: It is
mentioned in the gPXE project
(http://etherboot.org/wiki/soc/2006/derekpryor/proposal) but I didn't
see any follow-up on the proposal from users, and it is unclear how it
has been used and tested. So a completely secure x86 network boot seems
a future endeavor.
What I can see is that Python scripts leveraging SSL using openssl would
offer a very simple, platform-independent solution using the
standardized portions of wanboot. All authentication and encryption
would be handled at the SSL socket layer and would be transparent to
both the client and server.
What is less clear to me is how much coding to extend this
SPARC-customized solution to x86 would require.
Also, there is the question of how much to invest in a
platform-independent means of AI delivering SSL certificates with the
user providing HMAC and key: how much is this feature worth?
So to recap, to securely deliver profiles, I would propose either:
1) a simple Python client/server solution, obtaining SSL certificates
through other methods, or
2) porting the wanbootfs-fetching client side of wanboot to a
cross-platform user-mode application, and adding support to wanboot-cgi
to add in profiles written into wanbootfs on the server side by a
profile locator script
Given:
- considerable code porting (SPARC->x86, standalone->user-mode)
- efforts to make code build platform-independent
- the limitations of having a real secure PXE network boot in the first
place
- uncertain demand for certificates going to the x86 platform via
entering HMAC and key when other alternatives exist
I would support the Python solution (1) at this time.
William
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
