iSCSI login authentication

["Williams, Jim" <Jim.Williams@emulex.com>]

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."