[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IKE must have no Heirs
That's an interesting idea. I think one of the reasons for putting IKE in
user space might have been because it is so much more complicated than the
ESP/AH - it's much safer to keep it out of the kernel!
Chris
> -----Original Message-----
> From: Rick Smith at Secure Computing
> [mailto:rick_smith@securecomputing.com]
> Sent: 07 August 2001 19:49
> To: Alex Alten; Kory Hamzeh; Hallam-Baker, Phillip
> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com
> Subject: Re: IKE must have no Heirs
>
>
> At 02:28 AM 8/7/2001, Alex Alten wrote:
>
> >I second the motion. And also propose no port number (i.e. do the new
> >one over raw IP).
>
> There is a benefit to this approach if, in some future
> universe, we ever
> try to implement a protocol stack using least privilege to maximize
> security assurance. It gives us an easy way of putting all
> parts of IPsec
> within the same trust boundary and of keeping it better
> separated from
> other protocol processing.
>
> Otherwise you are stuck with a uniform level of trust for all of the
> software in the protocol stack, crypto and non-crypto, including the
> mechanism that binds ports to processes. I know, this isn't a
> problem today
> because protocol stacks run in kernel mode and therefore we
> (have no other
> choice but to) "trust" the entire protocol stack.
>
> It is, of course, feasible to ignore the issues of
> incremental trust and/or
> build additional mechanisms to bring together what is built
> asunder. But it
> seems cleaner, design-wise, to keep the key management close
> to the code
> that actually uses the resulting keys.
>
> Rick.
> smith@securecomputing.com
>
-----------------------------------------------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only. If you have received this message in error or
there are any problems please notify the originator immediately. The
unauthorized use, disclosure, copying or alteration of this message is
strictly forbidden. Baltimore Technologies plc will not be liable for direct,
special, indirect or consequential damages arising from alteration of the
contents of this message by a third party or as a result of any virus being
passed on.
In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.
This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.