On 07/ 8/10 07:00 PM, Dave Miner wrote:
William, just a bit more in-line below:
On 07/ 8/10 07:29 AM, William Schumann wrote:
On 07/ 6/10 11:07 PM, Dave Miner wrote:
William, a few comments/questions in line. Overall I think we're
getting near a workable answer.
On 07/ 2/10 12:59 PM, William Schumann wrote:
...
As an aside, I expect we'll have to look at enhancing wanboot to
support a stronger hash than SHA-1.
OK. That supports the notion that a more flexible solution offering a
wider variety of selectable ciphers may be in order.
Can you elaborate on what you're thinking here?
OpenSSL allows you to choose from a range of supported ciphers. From a
developmental level, their use is transparent; encryption and decryption
is encapsulated. For additional ciphers to be supported in
wanboot/wanboot-cgi, which is done at a low level, the support must be
added to the program source code on both ends. The PyOpenSSL module,
documented as only a wrapper to OpenSSL, would facilitate Python
client/server scripting.
To be considered: command set for managing keys and certificates for
client and server authentication. wanboot-cgi requires that this be
done
manually, offering tools to help in the process (wanbootutil(1M)), but
they only do creation and extraction and there are no tools for
listing
the hierarchy or deleting keys and certificates.
This would be part of installadm, right?
I was thinking of adding the support to wanbootutil(1M), although it
might be simpler to do from installadm with a similar set of
subcommands: keygen, keymgmt, p12split.
I would prefer to consolidate functionality into installadm since it
seems to align with the entities that installadm is expected to manage.
One approach could be for installadm to provide a wrapper to a
wanbootutil enhanced with support for the AI hierarchy:
CID->service->server, which could avoid replication of wanbootutil code
within installadm. Would that suffice?
...
manifests and install security in general: a specific user can be
identified via the client certificate, and the user receives an SC
manifest based on that identity instead of other criteria, such as AI
service or MAC address. For example, if a client certificate is
used for
a specific installing user, an SC manifest named after that user could
be automatically sent without the need for a custom client. This is
not
proposed - just offered for consideration.
I think it's useful to consider, though wouldn't we need cert support
in OBP?
Not if the boot were restructured: first download the generic bootfile,
run it, then supply the certificate later. Neither the bootfile nor the
rootfs are encrypted presently.
So we'd let unauthenticated clients at least boot to the OS, but not
able to go any further?
Yes. That would be consistent with what can be done presently with
wanboot-cgi and a modified wanboot. Functionality would be limited to
what bootfile provides, which would require a careful look.
Something to note is what OBP in itself provides. OBP provides
permanent secure storage for the keys:
# ok set-security-key wanboot-hmac-sha1 <sha1 key string>
# ok set-security-key wanboot-3des <3des key string>
(which is not as interesting for performing installations as it would be
for a system that routinely wanbooted). I don't think that OBP provides
any authentication or decryption in itself - it is able to kickoff the
bootfile download, not decrypt it or do SSL/TLS handshaking.
On the x86 side, PXE does not seem to provide any SSL support, so the
first download cannot be secured. gPXE does seem to support SSL
authentication - development appears to be very recent.
William
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
