[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: my minutes from the end client tunnel config discussion
> Pertinent issues that are important to get working road
> warrior/gateway tunnels:
> 1. end client has no permanent IP address. The ID payload
> will therefore be FQDN or user@FQDN.
Or ID_DER_ASN1_DN-- the DER encoding of the DN of the certificate.
> 2. due to #1, and the fact that the ID payload is not sent
> until the third exchange, a road warrior can not use
> pre-shared-keys for ISAKMP using main mode. The right
> pre-shared-key can not be selected. Section 5.4 of
> isakmp-oakley-06.txt mentions this. Agressive mode can be
> used, but obviously, it does not provide identity protection.
This is mitigated by the use of the ID_KEY_ID type. From the DOI:
4.6.2.12 ID_KEY_ID
The ID_KEY_ID type specifies an opaque byte stream which may be used
to pass vendor-specific information necessary to identify which pre-
shared key should be used to authenticate Aggressive mode
negotiations.
This way a peer's ability to pass an ID of, say, "skdruhfak" and an associated
pre-shared key of, say, "jlkert6y9e4h" would authenticate the peer without
leaking its real identity. Note that this type has to be in the group of
DOI=0 ID types that Doug is putting in the base ISAKMP document.
> 3. a way is needed to configure the road warrior's inner
> tunnel address. Roy Pereira's isakmp-mode-cfg is an initial attempt.
> 4. we need some textual information in the nofity
> messages. MCR will be writing a document.
I like this very much.
> 5. the bootstrap problem was declared out of scope for
> IPsecond.
> 6. we need to define *exactly* what goes into certificates
> used on road warrior nodes. Rodney has a document in
> preperation that addresses this for both end node and
> gateways.
> 7. we discussed whether or not policy configuration should
> be in scope for IPsecond.
Dan.
References: