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:
...
Also proposed is to modify wanboot:
- adding cross-platform support
- add SC manifests to the wanbootfs, whose transmission is secured
Advantages of leveraging wanboot:
- time-tested
- supports high level of security as well as encryptions that are more
difficult to decrypt without keys
- hash digest computation is optimized
Disadvantages of leveraging wanboot:
- ON consolidation, not install consolidation
- must add x86 support, although research indicates that the SPARC-only
wanboot code is mostly high-level, and lower level code is supported
cross-platform
- encryption options limited to 3des and aes key types
- only sha1 hash supported
- perhaps more maintainable, extensible, flexible with more code modules
to leverage if rewritten in Python
- receipt of wanbootfs would have to be decoupled from ramdisk code
under SPARC to instead write the wanbootfs (hsfs) to /tmp for x86
- client cannot presently submit a certificate as for IPS - the key and
HMAC must first be extracted
I'm not sure I understand exactly how you'll leverage the existing
wanboot program. It's a standalone second stage boot loader for SPARC,
so it seems like you'd have to rebuild it for x86 as a userland program?
Yes, that would be the plan. As indicated above, most of the code is
platform-independent - only the highest-level code (wanboot.c) is
SPARC-only. How this would be done within the existing ON consolidation
source framework without replicating code might be considerably more
difficult than coding it separately in the install consolidation in Python.
Remember that there is no install consolidation for the long term; all
of the work is going into ON, so let's not have consolidation boundaries
play into decision-making.
There is, as I recall, precedent for sharing code between standalone and
userland programs in ON. I'm pretty certain we do this in existing
networking code, but it's been a while.
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?
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.
To be considered: what methods for the installing user to provide key
and certificate information are feasible:
- hand-typing
- copying from or referencing removable media such as:
--- USB stick
--- bootable AI media
- copying from a secure network local to the AI client: wget, web
browser, NFS, scp
- secure authentication server - from console web browser, user supplies
password to receive certificate which can be used to fetch SC manifest
Any reason we wouldn't allow all of the above?
They can all be allowed. Means of providing keys or certificates to the
client can be considered orthogonal to security on the AI server.
Additional security notes
George Davis has been so kind as to post a menu-driven script to
automate and guide the user through generation, placement, and
extraction of the keys and certificates:
http://www.sun.com/bigadmin/jsp/descFile.jsp?url=descAll/solaris_wanboot_set
The notion of client authentication opens another possibility for SC
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?
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
