[Fwd: Re: [Fed-Talk] OS X, L2TP/IPsec, and Cisco VPN3000s]
[Fwd: Re: [Fed-Talk] OS X, L2TP/IPsec, and Cisco VPN3000s]
- Subject: [Fwd: Re: [Fed-Talk] OS X, L2TP/IPsec, and Cisco VPN3000s]
- From: "Timothy J. Miller" <email@hidden>
- Date: Mon, 01 May 2006 10:28:42 -0500
Back to an old issue, but now with New Workaround(tm).
Quickie background for everyone: The AF is moving to L2TP/IPsec VPNs
using CAC user authentication. This is a solution I demonstrated in my
day job supporting the AF PKI SPO, and have been evangelizing for the
last 18 months. Now there's some traction; guidance will be coming from
AFCA soon built around my solution.
Features: The connection uses certificates for IPsec authentication;
these must be issued specially to the machine. This also provides a
technical means for denying unapproved equipment from using the VPN,
even if the user has everything else they need. No contaminated,
poorly-managed home machines need apply. :) It then uses EAP-TLS for
L2TP authentication, which will use the CAC at the client end.
I've spent a lot of my time recently working on getting a device
certificate issuance capability up and running along with fielding phone
calls about the solution from every AF org I can name, plus from Army
and Navy.
It works like a champ with Windows.
But it wouldn't work with the Mac (not that the AF cares, but *I* do).
L2TP can be configured to use the CAC for user authentication, and IPsec
authentication can use a device certificate (add the key and cert to the
System keychain). All my trust points were correct, and it *should*
have worked. What I could see happening was that the IPsec SA would
complete as far as the Cisco VPN 3000 Concentrator was concerned, but
the Mac would drop the connection and complain that the VPN3K
certificate identity information was invalid.
I did some digging and found that Tiger (and presumably before, but I
can't test Panther any more) requires that the VPN3K IPsec cert have the
DNS or IP name included in the subjectAlternativeName certificate
extension. No problem; I got new certs cut with the dNSName field
included in the SAN and tried again.
Still didn't work. Same error.
Eventually I gave up and logged a bug through Appleseed for 10.4.6.
After a couple of back'n'forths exchanging logs, I got this from Apple
this morning (long after the 10.4.6 seed concluded, of course):
"""
Engineering has provided additional feedback regarding the problem you
reported.
The Cisco server is sending 3 certificates, but racoon currently ignores
all but the first. The connection is being rejected because the subject
name of the first certificate does not match the ID sent by the Cisco
server in the ID payload. I also noticed that there is no subject
alternate name field in the first certificate. Since the others were
not decoded by racoon, I don't know what their contents was.
There may be a work around for this problem. If you can get the Cisco
server administrator to setup a group on the Cisco server with just the
correct certificate then the client can connect using the Cisco group
and presumably get only the one correct certificate. You will need the
latest software update from Apple which contains support for groups in
Internet Connect. I think this should work if setup correctly.
"""
Now here's what's really happening: DoD end-entity certificates come
from an issuing CA, which itself descends from the root. The tree is 2
deep. So any time a DoD certificate is exchanged, it *should* be sent
with the chain so that we don't have to rely on the other party having
all of the issuers--just the root. When racoon (the process that runs
IKE negotiation on OS X) gets the cert chain during IKE as a set of CERT
payloads from the VPN3k it processes only the first one (which turns out
not to be the actual end-entity certificate. Since this cert does *not*
(obviously) have the dNSName in the SAN, racoon discards the association.
Now, IKEv1 was unclear on what to do about certificate chains, but IKEv2
is very clear. Either way, the DoD CA certificate it's trying to
process as the identity cert of the VPN3k is *not* suitable for the job
because basicConstraints is set and marked critical. This identifies
the cert as being a CA cert, and the critical marking means that if
racoon *must* discard this certificate if it's being used for anything
other than certificate validation. If anything, racoon should discard
that cert and process the *next* one.
Clearly, racoon is bugged. I re-submitted with the above analysis, and
hopefully it will be fixed.
However, this does present a workaround. VPN3K SAs can be configured
(in Configuration->Policy Management->Traffic Management->SAs) to offer
only the identity certificate during IKE. When this is done, the Tiger
L2TP/IPsec connection completes--and it will correctly use the CAC for
L2TP authentication. :)
And it *still* works with Windows.
-- Tim
--- Begin Message ---
- Subject: Re: [Fed-Talk] OS X, L2TP/IPsec, and Cisco VPN3000s
- From: Shawn Geddis <email@hidden>
- Date: Wed, 1 Feb 2006 09:32:20 -0500
Tim,
Will followup later today on this... under a crunch and do not have
adequate time to fully clarify this for you right now, but I wanted
you to know you actually need my help on this... :)
-Shawn
On Feb 1, 2006, at 9:23 AM, Timothy J Miller wrote:
Has anyone had any success getting OS X 10.4.x L2TP/IPsec to
negotiate an SA with a Cisco VPN3000 concentrator with certificate
authenticated IPsec? I've gotten to the point where main mode is
complete (as far as the concentrator is concerned), but OS X
terminates the nascent SA because (it says) the certificate
identity is invalid.
As far as I can tell, the only IPsec certificate profile
requirements OS X is supposed to have to IPsec peer certificates is
the FQDN in the subjectAlternativeName. Which I have. But for the
life of me I can't get it to work.
Pointers?
-- Tim _______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
- Shawn
___________________________________________
Shawn Geddis T (703) 264-5103
Security Consulting Engineer C (703) 623-9329
Apple Enterprise Sales email@hidden
Apple Computer, Inc.
1892 Preston White Drive T (703) 264-5100
Reston, VA 20191
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
--- End Message ---
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden