[strongSwan-dev] Pull request for external-authorization plugin
Vyronas Tsingaras
vtsingaras at it.auth.gr
Thu Jul 31 10:09:53 CEST 2014
So what you propose is to just use get_other_eap_id?
Does strongswan *know* what type the identity is or is it just a string for it?
On 31 July 2014 11:06:06 EEST, Martin Willi <martin at strongswan.org> wrote:
>
>> How does it look now? The "eap" : "ike" part is to make it easy to
>scripts to
>> differentiate what type of identity it is.
>
>True, but how does this scheme work if you want to pass both
>identities?
>Or someone wants to add other options, such as the peer address,
>certificate information, etc.?
>
>With that approach, you'd end up with an argument-name argument-value
>list, but the names are not that meaningful. I'd prefer environment
>variables, as you won't need any argument parsing in the callee. Just
>checking the value for get_other_eap_id() is sufficient in most cases,
>but we definitely should consider extensibility of that interface.
>
>> We have a conn that uses rightauth=pubkey (IKE id that is the DN of
>the
>> X.509 cert)
>
>With pubkey authentication, the IKE identity can be anything else than
>a
>DN. A peer for example may use an e-mail or IP as IKE identity (which
>is
>contained in the cert as subjectAltName).
>
>> So our script can parse for the email when argv[1] is ike and it
>knows
>> it already is an email if argv[1] is eap
>
>EAP or XAuth identities do not have to be e-mail addresses. Implying
>the
>identity type from the getter does not work.
>
>Regards
>Martin
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20140731/8cf36ded/attachment-0001.html>
More information about the Dev
mailing list