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

RE: Position statement on IKE development



Derek,

	My point is not that PFS is bad, but that the imposition of a
particular set of design priorities led to the very important properties of
usability and deployability to be left out.

	The problem is as you say the means by which the keys are ultimately
authenticated. It is not the cryptography. This is a complex task which is
expensive to manage if the semantics of the trust network are complex and
management takes place in devices at the periphery of the network.

	One solution is the SSL solution where the trust semantics are made
very simple. Unfortunately people don't seem to like that solution, even
though it is the only large scale open PKI that we have people using every
day for real business.

	If people want to have a complex set of trust semantics than the
only way to deploy the system is to provide a mechanism that allows the
trust path processing to be delegated to a trust service - see XKMS
[www.xmltrustcenter.org].


	I would also like to be able to delegate the process of key
agreement. This is because key agreement is an expensive operation that
expensive database engines and routers have no business doing and because
high end crypto hardware is expensive.

	
	That said there are a set of simplifications to IKE that could be
achieved immediately:

1)	Just decide what type of public key encryption you are going to use,
encryption or signature. There is certainly an ongoing need for algorithm
replacement, but allowing each party to chose from encryption/signature
simply quadruples the work with zero added security.

	At this point we have two public key signature algorithms in general
use and one encryption. So I would pick the signature, all things being
equal.

2)	Separate the credential download. In most cases Alice has Bob's
certificate cached from a previous interaction. If Alice is trying to talk
to Bob and does not have a credential then she should either (1) make a
credential request of Bob or (2) receive the credential in an error message
from Bob.

3)	Get rid of the negotiation assumption generally. At this point we
have 1 working digest function, 2 acceptable symmetric ciphers, 1 key
agreement and 2 public key algorithms. Alice should start with the
assumption that Bob is going to accept what she sends (after all she
probably has the information cached). If that is a false assumption then Bob
can send her an error message saying (I don't do X). 
  
4)	If you want to have the documents reviewed by the cryptography field
generally PRESENT THEM TYPESET. This is the 3rd millenium, we don't use
teletypes any more. Trying to read a crypto protocol with subscripts is bad
enough. Reading K_X, K_AB_X etc is a turn off for anyone. I don't know of a
single cryptographer who can't afford a bit mapped screen.


		Phill


Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@xxxxxxxxxxxx
781 245 6996 x227


> -----Original Message-----
> From: Derek Atkins [mailto:warlord@xxxxxxx]
> Sent: Friday, August 03, 2001 5:18 PM
> To: Hallam-Baker, Phillip
> Cc: 'Marcus Leech'; msec@xxxxxxxxxxxxxxxxxxx; ietf-ipsra@xxxxxxxx;
> ipsec-policy@xxxxxxxx; ipsec@xxxxxxxxxxxxxxxxx
> Subject: Re: Position statement on IKE development
> 
> 
> I think certificate management (and distribution) within IKE is the
> biggest problem of all.  I want to talk to the host/printer/network
> device at address 1.2.3.4.  How do I get it's public key, and why do I
> want to trust it?
> 
> PFS is _EASY_ compared to that.  An ephemeral DH exchange solves PFS.
> But how do I authenticate?  Better, how do I authenticate on a GLOBAL
> scale?  Now _THAT_ is the hard problem (IMHO).
> 
> -derek
> 
> "Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx> writes:
> 
> > I have a different set of concerns, IPSEC is not being used 
> in cases where
> > it should have been the answer.
> > 
> > In particular the IEEE 802.11b WEP fiasco could have been 
> averted if the
> > designers had not been discouraged by the complexity of IPSEC.
> > 
> > Another issue is why can't I buy a printer that is IPSEC enabled?
> > 
> > I believe that the biggest problem with IPSEC is that the 
> search for a
> > certain view of perfect security has lead to a standard 
> that many have
> > bypassed altogether as too demanding.
> > 
> > Perfect Forward Secrecy is great, but I would rather have a 
> secure means of
> > connecting to my printer than the possibility of a 
> perfectly secure means in
> > ten years time.
> > 
> > End to end security is a good thing, but in many 
> applications the overhead
> > of negotiating trust relationships end to end is just too 
> high. How am I
> > expected to configure the end to end security on an 
> embedded device with no
> > console. Oh I use a web browser to connect to it, yes very 
> end to end.
> > 
> > 		Phill
> > 
> > 
> > 
> > Phillip Hallam-Baker FBCS C.Eng.
> > Principal Scientist
> > VeriSign Inc.
> > pbaker@xxxxxxxxxxxx
> > 781 245 6996 x227
> > 
> > 
> > > -----Original Message-----
> > > From: Marcus Leech [mailto:mleech@xxxxxxxxxxxxxxxxxx]
> > > Sent: Thursday, August 02, 2001 9:34 PM
> > > To: msec@xxxxxxxxxxxxxxxxxxx; ietf-ipsra@xxxxxxxx;
> > > ipsec-policy@xxxxxxxx; ipsec@xxxxxxxxxxxxxxxxx
> > > Subject: Position statement on IKE development
> > > 
> > > 
> > > I'm sending the attached ASCII TEXT document on behalf of 
> myself, Jeff
> > > Schiller, and
> > >   Steve Bellovin, to clarify our position with respect to IKE
> > > development. It is our hope
> > >   that it will clarify, to some extent, some fuzziness in 
> > > this area that
> > > has evolved over
> > >   the last year or so.
> > > 
> > 
> > 
> > ------_=_NextPart_000_01C11C5C.14D9EDC0
> > Content-Type: application/octet-stream;
> > 	name="Phillip Hallam-Baker (E-mail).vcf"
> > Content-Disposition: attachment;
> > 	filename="Phillip Hallam-Baker (E-mail).vcf"
> > 
> > BEGIN:VCARD
> > VERSION:2.1
> > N:Hallam-Baker;Phillip
> > FN:Phillip Hallam-Baker (E-mail)
> > ORG:VeriSign
> > TITLE:Principal Consultant
> > TEL;WORK;VOICE:(781) 245-6996 x227
> > EMAIL;PREF;INTERNET:hallam@xxxxxxxxxxxx
> > REV:20010214T163732Z
> > END:VCARD
> > 
> > ------_=_NextPart_000_01C11C5C.14D9EDC0--
> 
> -- 
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        warlord@xxxxxxx                        PGP key available
>  
 <<Phillip Hallam-Baker (E-mail).vcf>> 

Attachment: Phillip Hallam-Baker (E-mail).vcf
Description: Binary data