[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Charter



I think the intent of this clause is clear. The debate it is causing is
similar to the argument over the strength of XAuth.

E.g:

1) XAuth is stronger than IKE because it inherits the strength of IKE and
then tacks on an additional level of user-authentication. (I.e. for every
scenerio using IKE, there exists an equally secure or more secure scenario
using both IKE and XAuth).

v.s.

2) XAuth is weaker than IKE because it allows (uninformed?) administrators
to deploy potentially weak scenarios (e.g. group shared secrets) which are
possible using IKE, but which no one would consider deploying using IKE
alone.


So maybe the clause "Maintain or exceed security current strength" should be
reworded as follows:

1) Permit the user to maintain or exceed security current strength

or

2) Force the user to maintain or exceed security current strength

At least from a cryptographic perspective...


But the other things you mentioned are a good start. We should be examining
the security constraints which make ipsra logically distinct from other
scenerios. For example, identity protection is way more important for ipsra
than for static hosts.

Andrew
_______________________________________________
 Beauty without truth is insubstantial.
 Truth without beauty is unbearable.


> -----Original Message-----
> From: Ari Huttunen [mailto:Ari.Huttunen@xxxxxxxxxxxxxxx]
> Sent: Monday, November 22, 1999 1:45 PM
> To: 'ipsra'
> Subject: Re: Charter
> 
> 
> Dan Harkins wrote:
> > > Some (high-level) general requirements:
> > >
> > > 4) Maintain or exceed security current strength
> > 
> > What does this mean? What is the "current strength" against 
> which we'll
> > measure the result to make sure we satisfy the requirement?
> 
> I suggest that we try to specify some representative usage
> situations, and try to estimate the required security features
> for each. 
> 
> One situation would be a typical corporation and a remotely
> connecting employee. Some of the security requirements could be:
> - Requirement for identity protection would be low 
> - Requirement for authentication and encryption would be high
> - The remote user would not be allowed any other internet 
>   connectivity to prevent creating holes in the corporation firewall.
> 
> A requirement for connectivity by a three letter agency would
> place heavy emphasis on identity protection..
> 
> A requirement for connectivity to a firewall or a central backbone
> router would place heavy emphasis on preventing DoS attacks..
> 
> Etc..
> 
> Having created a representative sample, we would specify which
> modes and authentication methods would be suitable for the task.
> A network administrator could then look for the closest 
> match when configuring the security of the system.
> 
> -- 
> Ari Huttunen                   phone: +358 9 859 900
> Senior Software Engineer       fax  : +358 9 8599 0452
> 
> Data Fellows Corporation       http://www.DataFellows.com 
> 
> F-Secure products: Integrated Solutions for Enterprise Security
>