Re: APOP - authentication..

] From: Ned Freed  <>
] To: Paul Leach
] Cc:  <fielding@avron.ICS.UCI.EDU>;  <>;
] <>
] Subject: Re: APOP - authentication..
] Date: Tuesday, February 20, 1996 3:00PM
] > Based on the comments about Digest when (I thnk it was Larry masinter)
] > was asked that it be reviewed by the www-security list,  and from the brief
] > description that Peter included in his message, it appears
] > that APOP authentication does not suffer from the replay
] > attack that was present in the then current Digest design.
] The current digest document lets the server choose between allowing 
old "nonce"
] values, in which case replay attacks are possible, or generating a new one
] every time, in which case replay attacks are no longer possible against a
] single server.

Why?  There's an option to be just "kinda secure"? It sounds like if 
someone can sniff the wire to get an in-the-clear password, then they 
can sniff it to get replayable digests. In which case, digest is _not_ 
a whole lot better than passwords, as some claimed when the future of 
digest was being discussed on the list a while back.

(I haven't seen a version announced later than the one trashed on 
www-security, nor since Jeff Hostetler said on 1/24/96 to Larry 
Masinter that they would be submitting a new digest draft.  I could 
easily have just missed it -- is there a new one?)

] There is still some danger, however, in that the only material included under
] the checksum is the username and password. Should someone elect to 
use the same
] password with two different servers there is some possibility that should the
] nonce value sequences from the two servers overlap there would be some
] vulnerability to a replay attack of a client's interaction with one server on
] the other server.

Do you mean "the only _other_ material" is the username and password, 
in addition to some nonce generated by the server?

] This could be easily defeated by using hash values for the nonce sequence
] rather than a strict ascending sequence as implied by the specification. And
] POP3's APOP is not necessarily immune from this attack, since there is no
] mechanism that guarantees that two different servers will generate different
] sequences of one-time values.

Based on my reading of Peter's post, in APOP, the material covered by 
the digest includes the hostname.  (the "apop-realm" is digested, and 
it is a nonce concatenated with the hostname...) Why not just do the 
same for the HTTP version? Then there wouldn't be the possibility that 
the same password on different servers would generate the same digest.

] I would prefer it if the nonce values in the digest specifications 
were simply
] strings and the specification recommended inclusion of server-unique
] information in the string. But this is a nit and nothing more -- it isn't
] enough of a deficiency in the digest specification to warrant the addition of
] APOP as yet another securty scheme. And even if it were, I think the better
] approach would be to fix the digest specification.

I can't say until I've seen the new draft. BTW: I don't see APOP as 
"another" scheme -- if it's easier to just use APOP than fix digest, 
then I can't see why we should just use APOP. No one seems to have 
enunciated the reasons for digest -- only Roy's claim that there's no 
chance anyone will implement anything other that digest, without 
explaining why.


Received on Tuesday, 20 February 1996 17:40:59 UTC