Path: utzoo!utgpu!watserv1!watmath!att!pacbell.com!ucsd!ucbvax!hplabs!otter.hpl.hp.com!otter!csi
From: csi@otter.hpl.hp.com (Colin I'Anson)
Newsgroups: comp.protocols.iso.dev-environ
Subject: Re: X.509: Is it secure?
Message-ID: <2630001@otter.hpl.hp.com>
Date: 29 Jan 91 10:07:04 GMT
References: <MICKY.91Jan21181254@bahia.cs.tu-berlin.de>
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Lines: 54

defined in there. Please can someone with the standards at hand bring
some light in the ISO-darkness (My versions are from July 1990, but I don't
know of significant differences to the 1988 versions).

--  Light in the ISO-darkness seems very optimistic but here goes 

1. In clause 5.4.2 a second version of Protected Simple Authentication ...

-- Protected simple authentication was a last minute addition to X.509 after
   somebody accidently called simple authentication, weak authentication!
   This unfortunate use of terms exposed a problem for people who wanted
   security but not the extensive use of cryptographic functions required
   for strong authentication.

-- I can't remember the offical reasons for its inclusion but I can 
   recall when - October/November 1987 at the Gloucester meeting.  Perhaps
   somebody out there still has a copy of the original submission.

-- The length of the passwords can be up to 128 octets in the CCITT case
   making it difficult to break into if the right function is chosen.

2. In clause 9.2 a protocol for one-way authentication is described:
   "1. A generates rA, a non-repeating number, which is used to detect
   replay attacks and to prevent forgery"

   What is meant by "non-repeating":

-- The purpose of rA is to make the digital signature of the construct
   different in every case.  So why not use a sequence of numbers 1, 2,
   3, 4, etc every time a signature is made.  This provides a record of
   the number of the signature and might help to identify if one of the
   sequence is missing.

3. There have been an article concerning the security of the
   authentication framework:

   ...

   In my opinion B would check the nonce rA, detect the replay and
   refuse the connection. (See question 2). Any comments?

-- Nice idea but can you guarantee that this will work in all cases?
   I think that there is a case where, if the most recent message from 
   A to B is intercepted before reaching B, C will obtain the required
   arguments to carry out the masquerade without detection.

-- Also, the fix suggested for the three way authentication is progressing
   through ISO and CCITT.

-- As an aside, is there any use being made of this particular three way
   authentication process in ISO or CCITT?

Colin I'Anson
HP Labs, Bristol, England