RE: iSCSI login authentication

[vince_cavanna@agilent.com]

I would like to add another question to Jim's.
Does anyone know how CHAP and SRP justify their apparent lack of protection
from denial of service attack prior to authentication? My understanding is
that IKE attempts to provide such protection by exchanging cookies at the
beginning of the phase 1 exchange.
Vince


|-----Original Message-----
|From: Williams, Jim [mailto:Jim.Williams@emulex.com]
|Sent: Friday, April 26, 2002 7:25 AM
|To: 'ips@ece.cmu.edu'
|Subject: iSCSI login authentication
|
|
|Some questions on iSCSI login authentication follow.
|There is discussion as to whether SRP or DH-CHAP may
|be required, however I think the following questions
|would apply to either.  Apologies in advance for any
|misunderstandings of the current proposals by me.
|
|draft-ietf-ips-security-11 states:
|
| "Computational horsepower should be available to
|  perform a reasonable amount of
|  exponentiation as part of authentication [...] for
|  connection setup."
|
|This does not seem unreasonable, but I am concerned that there
|are no numbers or references to back this up (sorry if I missed
|them).  There is a detailed appendix on IPSec encryption and
|authentication computation requirements, but what are the
|requirements for exponentiation.
|
|How long is it acceptable to take in performing or verifying
|authentication?  How big are the numbers involved?  There are
|public domain authentication software.  Have experiments
|been done to determine the computation requirements on
|a typical embedded processor versus number size?
|
|
|draft-ietf-ips-iscsi-12 states:
|
|    "N [for SRP] is required to be a Sophie-German prime.
|    [...] N MUST be at least 768 bits. [...]
|    The Initiator MUST verify that 
|    they satisfy the above requirements. [...] This 
|    verification MAY start by trying to match N and g with a 
|    well-known group that satisfies the above requirements."
|
|What is the maximum length of N?  Also stated is:
|
|    "The length of 
|     N,g,s,A,B,M in binary form (not the length of the
|     character string that represents them in encoded form)
|     MUST not exceed 1024 bytes."
|
|1024 bytes is 8192 bits.  Do we really want to allow numbers
|that big?  Forcing an initiator or target to do computation
|on excessive large numbers may constitute a denial of service
|attack if the computations take excessively long times.  On
|the other hand, if targets and initiators reject excessively
|big numbers, while the other end requires them, there is
|an interoperability failure.  One approach is to let the
|market sort out what constitutes de facto requirements 
|for login authentication, but it would be better if the
|specification were specific on what size number SHOULD
|be offered and accepted for authentication.
|
|Also, why is selecting N and g from a well-known group a
|"MAY"?  Verifying that N is a Sophie-German prime by
|means of probabilistic primality testing requires
|significantly more computation than the authentication
|itself.  Also letting a target or initiator choses
|its own custimized value of N does not seem 
|conducive to good security.
|
|I would suggest more appropriate might be something
|like:  "N MUST be at least 768 bits.  N SHOULD be no larger
|than <TBD> bits and MUST be selected from the well-known
|group <xyz>.  If a target or initiator receives a proposed
|value of N larger than <TBD> bits it MAY be rejected.
|and if it is not contained in the
|well-known group <xyz>, this value SHOULD (MUST??) 
|be rejected.
|Otherwise the value of N SHOULD be accepted."
|