micky@opal.cs.tu-berlin.de (Michael Gehrke) (01/22/91)
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.
------------------------------------------------------------------------------csi@otter.hpl.hp.com (Colin I'Anson) (01/29/91)
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