1. Are there any security requirements documented for this project? [X] No a. What security issues are being addressed or potentially introduced by your project. See design document for details. 2. For each service that is created, installed, used, or depended upon, describe, how it is compliant with the Install-Time Security Policy ( http://sac/cgi-bin/bp.cgi?NAME=ITS.bp and/or http://www.opensolaris.org/os/community/arc/policies/ITS/ a. Specifically, how does each outbound service meet the protection requirements using: SVC1, SVC2, or SVC[3,4] including how OUT[1-3] protection is enforced. b. Specifically, how does each inbound service meet the protection requirements using: SVC1, SVC2, or SVC[3,4] including how IN[1,2] protection is enforced. Combined answer to (a) and (b) SVC2 (feature disabled by default); when enabled, the key management daemon enforces IN1, IN2, OUT1, OUT2, and OUT3 for key management traffic, and (with the assistance of key management) the kernel provides IN1,2 and OUT1,2,3 service for all IP traffic identified by an administrator as needing IPsec protection. c. How are the other aspects of the policy met ( e.g., warning to the administration about install options which are non-compliant) [ answer ] d. Also, list the service/application to which this project will communicate and the mechanism used (if external network interfaces are used, or the connection uses purely local interconnects, and if IP based list static/dynamic ports used) IP protocols 50 and 51 (ESP & AH) UDP port 500 and 4500 (IKE) 3. Describe how to disable each service from your project and the side effects (e.g. dependencies) of doing so. no change from existing IPsec and TX svcadm disable svc:/network/ipsec/ike side-effects: if IPsec policy exists, will prevent creation of new security associations -- will stop IPsec protected bits from moving. svcadm disable svc:/network/ipsec/policy side effects: outbound traffic sent unprotected; unprotected inbound traffic will be accepted. 4. For each service, discuss how it protects its communications from: theft, replay, content change and user impersonation within the following sub-sections: a. Does your service make decisions based on user, host or service identities? [X] Yes 1. Describe how your project authenticates or discover the host, user, or services identity? [ answer ] authentication is via either (a) shared secret found in /etc/inet/secret/ike.preshared, or (b) public key authentication using certificates. 2. If authentication is done by another component explain how you obtain this information and why you believe its authentic. in case (b), there are a list of trusted certificates configured in /etc/inet/ike/config. 3. If your project authenticates, explain the authentication process including any standards or existing components used. 4. In addition, describe what happens if the authentication process fails. if authentication fails, security associations aren't created and bits don't move. 5. If passwords or passphrases are used, discuss how they are protected from host or network-based theft, protected if stored beyond authentication, how they can be changed, and any validity checking which occurs. no change from existing IPsec; highest security option available is to store authentication key in secure keystore (such as SCA4000/SCA6000). b. Does your project make decisions about whether a requestor may access a particular resource? [X] Yes Explain how this occurs for both successful and unsuccessful access requests. in addition to existing IPsec mechanisms, the kernel also enforces a label match on transmit between each outbound packet and the outbound labeled SA; if key management declines to create an SA with the desired label, bits don't move. For inbound traffic, the kernel enforces a label match between each inbound packet and the process which will receive it; this project allows the label to come from the security association used to protect the packet, cryptographically binding the label to the packet contents. c. Does your project protect its communications from passive listeners on the network? [X] Yes Explain the techniques used to accomplish this. labels are protected by being an implicit property of the security association used -- an eavesdropper only sees a 32-bit random SPI value followed by the encrypted payload. d. Describe how host and network-based access control are provided (e.g., this could be provided through technologies such as host-based firewalls/IPsec or application-level controls such as TCP Wrappers). IPsec already provides filtering based on ip address. e. Does your service protect the integrity of its communications over the network? [X] Yes Explain the techniques used to accomplish this. IPsec already does this for user data; this project [?] No Explain why not. [ answer ] f. Describe how network communication is protected against replay attacks in which a partial record of an earlier network exchange is replayed [ answer ] g. Describe how your network communications could be exploited by a denial of service (DoS) attack. (For instance, what resources are allocated during session setup before the requestor has been authenticated) [ answer ] 5. For each network (e.g., RPC over IP, TCP/IP, Serial, etc.) used by a project describe the following: see design document. 6. Does this project use secret information (e.g. passwords, passphrases, PINs or equivalent authenticators) during authentication and/or authorization? [X] Yes a. Describe all methods for how this secret information can be obtained (e.g. user prompted interactively.) No change from existing solaris IPsec. 1. If the secret information can be obtained via command line or environment variable, explain how the project complies with the SAC Reusable Passwords policy at: http://sac.eng/swg/Security/recommendations/reusable_password_policy_v1.0.txt N/A. 2. If the secret information can be obtained from persistent storage (e.g. file), explain how the storage is protected and compliant with the SAC Storing Reusable Passwords policy at: http://sac.eng/swg/Security/recommendations/SecSWG_Policy_ReusablePW_FS_v1.0.txt Existing IPsec code allows both compliant and non-compliant usage. This project is not changing any of this; work on another RFE (ikeadm setpin) is underway to make improvements in this area. b. Describe how the secret information is: created, provisioned, updated, revoked, and checked for policies regarding its content (e.g. password strength checks.) No change from existing solaris IPsec. c. How is this secret information expunged from the project's memory after use (e.g. so it doesn't appear in core files?) No change from existing IPsec - in general we memset/bzero before free for all sensitive keying material. 7. Describe how the project uses the file system in a way that is compliant with the FILE SYSTEM GUIDANCE section of the Install-Time Security Policy (see above) for cases other than storage of secret information (previous question). No change from existing solaris IPsec 8. Does a non-privileged (e.g., not having access equivalent to uid 0 on pre-RBAC/Least Privilege OEs) user have access to all project functionality? An appropriately privileged administrator must set up policy rules which apply to traffic from both privileged and unprivileged processes. [*] Yes a. Describe why there are no potential RASS (Reliability, Availability, Serviceability, and Security) reasons to restrict non-privileged access. non-privileged account gets to move bits under labeled IPsec protection if the privileged administrator sets things up to allow it. [*] No a. Describe how/where authentication and authorization checks are done. authorization checks are performed within the kernel (when it decides whether traffic must be ipsec protected) and within the privileged key management daemon (when it decides whether to permit creation of a security assocation). authentication occurs within the key management daemon. b. List the roles, rights, and authorizations needed to access the functionality included in this project. no change from existing mechanisms. c. Does your project perform authorization checking itself or does it use another component? If itself, explain how this occurs and why this project has its own authorization system. in addition to the existing IPsec and TX mechanisms, the key management daemon now consults the TX tn*db databases to determine label ranges of peers. 9. Except for networking (discussed above), does this project use cryptography for any purpose? [X] No All crypto is for data in flight. 10. Is any privileged user or group account (e.g., suid root, or other privileged setting mechanism) software part of your project? [_?_] Yes a. Describe how the principle of least privilege (e.g. daemon dropping privileges once no longer needed) has been applied. ike daemon starts as root and drops unneeded privileges ASAP; privileges are added to the EFFECTIVE set only for short periods of time. b. In addition, list all privileges required for this software. SYS_IP_CONFIG NET_PRIVADDR NET_MAC_AWARE NET_MAC_IMPLICIT (new; see design doc) FILE_DAC_WRITE 11. Are any log, error, FMA, or audit events generated? Note - this question applies to all auditing mechanisms, whether implemented in Solaris auditing, J2SEs logging facility, or Windows event logging [_?_] Yes a. List all security error events that may be generated and their causes. [ answer ] b. Will this project generate any audit records? [_?_] Yes List those events for which you will generate audit records. [ answer ] [_?_] No Describe why not. [ answer ] [_?_] No TBD - would appreciate input on areas where audit might be appropriate. 12. Will the project undergo a security evaluation/certification by itself or as part of a larger product (e.g. Solaris releases are certified against the Common Criteria's CAPP at EAL4)? [_?_] Yes a. Against which standards will it be evaluated? [_?_] Common Criteria: which protection profiles (e.g., CAPP) and to what assurance level (e.g., EAL4) [ answer ] [_?_] FIPS 140-2: what level (1 to 4) is the evaluation? [ answer ] [_?_] Other: Provide specific details [ answer ] b. What already-evaluated mechanisms (e.g., auditing) will your project be using to make this possible and as simple as possible? [ answer ] c. What already-evaluated mechanisms was your project not able to leverage and why? [ answer ] [_?_] No TBD. It seems likely that this will be evaluated at some point in the future but this will happen as part of a solaris release. 13. How does the project provide for failsafe defaults such that the security is not compromised? (For example, how does the project ensure that the security of the product isn't compromised by corrupted or missing configuration files) This project does not change the behavior of solaris IKE/IPsec with respect to this requirement.