Markus Koellner wrote:
>
>> I have been thinking about introducing a prompt for the passphrase
>> of a protected private key file if the passphrase field in ipsec.secrets
>> is left intentionally empty. This would mean that the pluto process would
>> have to connect to a console window either when FreeS/WAN starts up or
>> when
>>
>> ipsec auto --rereadsecrets
>>
>> is executed. Otherwise the prompt would not pop up.
>
>
> This seems reasonable as a first step.
>
> You talked about a project with RSA SmartCards a while ago which
> you want to combine with your X.509Patch so the private key
> resides on the external card.
> Are there any news ?
>
Still two weeks to go until the end of the summer term. Then
after some relaxing I will have time to work on some features
that I optimistically anounced a long time ago. Among them:
- support of asynchronous access to HTTP and LDAP servers
hosting CRLs, host certificates and as an experimental feature
attribute certificates. I want to model the access after the
asynchronous DNS as currently implemented by FreeS/WAN.
- support of keeping private keys safely in a smartcard or at
least securing the private key file.
>> The updown script gives you the possibility to do access control
>> on users. Just look up the user ID contained in the environment
>> variable $PLUTO_PEER_ID in your access control list prior to
>> inserting a dynamical firewall rule that lets the user in.
>
>
> This could be a solution to a question which i asked to myself:
>
> You have this very practical feature "rightsubnetwithin" where you
> can install one connection definition for hundreds of roadwarriors.
> But then the security depends entirely on the CRList.
>
> The disadvantage is you can't disable a client for a while and then
> enable it, so the client can work again (e.g when he had paid the
> outstanding bills).
> By now you have to put the client on the CRList and then make a new
> cert which is very unpractical.
>
> A solution could be a default profile for all roadwarriors and a
> special profile with the rightid= of the *forbidden* client and a new
> parameter auto=deny (or something else) which denies this client
> while authentication in phase1.
>
> Then you have a double security (CRL + connection profile). And you
> can disable and enable a client whenever you want.
>
> Sure, a dynamical firewall based on the parameter $PLUTO_PEER_ID is
> a good hint but i'm a bit hesitant and unsure about a some kind of
> *magic* firewall which changes without my own knowledge. This sounds
> a bit old fashioned...
>
> Furthermore i think you should deny an unwanted client as early as
> possible and not after a successful cert-authentication with a
> dynamically loaded firewall rule.
A possible solution would be to use short-lived attribute certificates
which are in many respects very similar to Kerberos tickets. With
the LDAP lookup in place, FreeS/WAN could query an access control server
e.g. once a day to get an access granting certificate for a remote
user or host. Attribute certificates are bound to long-lived host
or user certificates. If the user does not pay his bill then as a
consequence no valid attribute certificate will be put on the LDAP
server whereas the user cert would remain valid and wouldn't have to
be revoked. Some new parameter like e.g. rightacl=... would have
to be defined for this purpose.
So much about my future plans.
Andreas
>
> Bye
> Markus
======================================================================
Andreas Steffen e-mail: andreas.steffen_at_strongsec.com
strongSec GmbH phone: +41 76 340 25 56
Alter Zürichweg 20 home: http://www.strongsec.com
CH-8952 Schlieren (Switzerland)
==========================================[strong internet security]==
_______________________________________________
Users mailing list
Users_at_lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.3 : Mon Jul 29 2002 - 05:20:19 CEST