🚀 go-pugleaf

I tried to post this article before, but haven't seen it in this
newsgroup until now. If --you-- have already seen it, forget about:

Part 8 of CCITT X.500, or X.509, defines an authentication framework for
other applications as well as for the directory itself. I have some
questions concerning the strong and simple authentication protocols
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).

1. In clause 5.4.2 a second version of Protected Simple Authentication 
   is described:
   --Protected2-- is performed by applying a one-way function --f2--
   to --Protected1-- and could so be transmitted as part of an
   --Authenticator2 -- to a verifier to check the identity.

   Protected2 = f2 (t2, q2, Protected1)
   Authenticator1 = t1, t2, q1, q2, A, Protected1

   Why is this form more --secure-- than only constructing and transmitting
   --Protected1-- as part of --authenticator1--?

   Protected1 = f1 (t1, q2, A, PasswordA)
   Authenticator1 = t1, q1, A, Protected1

   I understand that if a cryptanalyst would try to break A's
   password by brute force, he would have the double amount of work to
   do, because of applying --f2-- and --f1-- for each possible
   password.

   Is this really more --secure--?
   Wouldn't it be better to require longer passwords?
   If I enlarge my password by 1 character, the time needed to
   crack the password will be in the average 13 times larger.

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":
   - A uses another nonce for each authentication with B?
   - A uses another nonce for each authentication?
   - There have to be systemwide different nonces for each
     authentication procedure (seems senseless)?

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

     Colin I'Anson, Chris Mitchell
     "Security Defects in {CCITT} Recommendation {X.509} -
      The Directory Authentication Framework"
     Computer Communication Review
     April 1990

   They say that the 3-way authentication protocol is defect. An
   intruder C sends B the following message:

     C-->B: A{0, rA, B}   
   
   "B responds (thinking it is talking to A, but actually talking to C)."
   In my opinion B would check the nonce rA, detect the replay and
   refuse the connection. (See question 2). Any comments?

   The same argument was given before in:
     Michael Burrows, Martin Abadi, Roger Needham
     "A Logic of Authentication",
     Proceedings of the 12 th. ACM Symposium on Operating Systems
     3. - 6. December 1989
 
Any comments on this are welcome. Thanks in advance, micky.

------------------------------------------------------------------------------
Michael Gehrke,                           E-Mail:  micky@opal.cs.tu-berlin.de
Technische Universit"at Berlin,           Telefon: 030/314-24618
Institut f"ur Angewandte Informatik,
Sekretariat FR 5-9,
Franklinstra"se 28/29,
1000 Berlin 10.
------------------------------------------------------------------------------
--
------------------------------------------------------------------------------
Michael Gehrke,                           E-Mail:  micky@opal.cs.tu-berlin.de
Technische Universit"at Berlin,           Telefon: 030/314-24618
Institut f"ur Angewandte Informatik,
Sekretariat FR 5-9,
Franklinstra"se 28/29,
1000 Berlin 10.
------------------------------------------------------------------------------