PLEASE do not use HTML e-mail. Some of us still use tty-based mailers, for
crying out loud! :)
Okay, on to your first question. Pardon they delay:
> Interoperating with Sun Solaris, it is not clear how the keys are
> getting generated on the solaris side of things. With an RFC
> compliant implementation of the key generation on a peer device, we
> can confirm that the following components of the key are the same:
>
> - SKEYID
> - SKEYID_a
> - SKEYID_d
> - SKEYID_e
> - Encryption key
Sounds good so far...
> However, from solaris debugging command currently provided (ikeadm
> dump p1), the encryption IV does not match during the initiation
> messaging (phase 1 SA setup exchange)
>
>
> The RFC details are (RFC2409 Appendix B) :
> " ....
> In phase 1, material for the initialization vector (IV material) for
> CBC mode encryption algorithms is derived from a hash of a
> concatenation of the initiator's public Diffie-Hellman value and the
> responder's public Diffie-Hellman value using the negotiated hash
> algorithm.
> ...."
You're missing the last sentence of the paragraph you partially quote:
Subsequent messages MUST use the last CBC encryption block from the
previous message as their initialization vector.
> Is the above the supported manner for Solaris implementation of the
> same?
If we interoperate with the peer, the answer MUST be yes.
You never said if you were successfully moving bits or not.
> Is the data obtained from ikeadm dump p1 accurate?
> # ikeadm dump p1
>
> IKESA: Cookies: Initiator 0xa730b61aa1000040 Responder
> 0xdbc2dbc2e43aa3ee
> IKESA: The local host is the initiator.
> IKESA: ISAKMP version 1.0; main mode (identity protect) exchange
> IKESA: Current state is SENT FINAL MSG
> XFORM: Authentication method: RSA signatures
> XFORM: Encryption alg: DES-CBC; Authentication alg: HMAC-SHA-1
> XFORM: PRF: HMAC SHA1; Oakley Group: 768-bit MODP
> XFORM: Phase 2 PFS is required (Oakley Group: 768-bit MODP)
> LOCIP: Address (Initiator):
> LOCIP: AF_INET: port 0, 47.135.48.67 (wcary3q9).
> REMIP: Address (Responder):
> REMIP: AF_INET: port 0, 47.138.180.110 <unknown>.
> LIFTM: Lifetime limits:
> LIFTM: 1440 seconds; 0 kbytes protected; 0 keymat provided.
> LIFTM: Current usage:
> LIFTM: SA was created at Fri 29 Sep 2006 02:04:18 PM EDT
> LIFTM: 3 kbytes protected; 0 keymat provided.
> LIFTM: Expiration info:
> LIFTM: SA expires in 1424 seconds, at Fri 29 Sep 2006 02:28:18 PM EDT
> STATS: 0 Quick Mode SAs created; 0 Quick Mode SAs deleted
> ERRS: 0 RX errors: 0 decryption, 0 hash, 0 other
> ERRS: 0 TX errors
> LOCID: Initiator identity, uid=0, type ASN.1 DER Distinguished Name
> LOCID: <cannot print>
> KEY: SKEYID (20 bytes): 92bef4d3265113191e451489afe6ad0956b361c1/160
> KEY: SKEYID_d (20 bytes): c723830571f56442e582de1ffc35cac91da56c09/160
> KEY: SKEYID_a (20 bytes): 0c7768716a4b1ccfb741c217debfbdb9283c959f/160
> KEY: SKEYID_e (20 bytes): f06760846025267ae4acc538f155af14ab986731/160
> KEY: Encryption key (8 bytes): f06760846025267a/64
> KEY: Initialization vector (8 bytes): 6570dbfb91b0d6c8/64
The IV that ikeadm dump obtains is drudged out of state that's in an OEMed
bit of code. It is *possible* we are drudging it from the wrong place in the
OEM IKE Phase I state.
If you are moving bits successfully, what problem ARE you trying to solve,
anyway? At worst (assuming you are interoperating), this is a bug in
in.iked's ikeadm(1m)-handling code. Because in.iked isn't in the "open" part
of OpenSolaris, you'll *probably* need to engage us through your support
contract. Before you do, however, ask me off-list for what data to provide.
Dan
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
