[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Edited Minutes of the 1/29/02 IPS Security Conference call

    These minutes have been edited somewhat.  Summary of important topics
    discussed on the call:
    - IKE Identity Payloads.  Allowing use of FQDNs in addition to IP
    	addresses as IKE identities will resolve an issue regarding
    	dynamic addresses raised on the list.  The entire list of
    	possible IKE identities needs to be reviewed as part of this change.
    - IPsec and authorization.  New iSCSI MIB model proposes to list IKE
    	identities for authorization purposes, iSNS can also help with this.
    - IPsec certificates.  A warning will be added about large keys increasing
    	the likelihood of IKE running into IP fragmentation which often
    	causes failure in practice.
    - Rekey intervals - The intervals specified in the draft were calculated
    	under overly pessimistic assumptions and hence are unduly short.
    	They'll be removed and replaced with a general description of the
    - Security policy, Send Targets and iSNS.  Independent of whether iSNS is in
    	use an iSCSI Initiator needs to know whether IPsec is needed to
    	a Target.  Beyond that, IKE can handle all required feature
    	iSNS can distribute the info about whether a target requires IPsec,
    	can store IKE proposals for convenience.  An attribute indicating
    	a Target requires IPsec will be added to SLPv2 for iSCSI.  The
    	way to deal with Send Targets is to make it homogeneous wrt IPsec
    	- if IPsec is used for the session on which the Send Targets is
    	performed, it's used to contact the Targets obtained.
    - Dangling SAs.  Paul Koning was correct about the prohibition of dangling
    	SAs being excessive.  The requirement to delete phase 2 SAs when the
    	corresponding phase 1 SA goes away will be removed.
    - Transport mode vs. tunnel mode.  A key observation is that unlike remote
    	access, IP Storage protocols do not generally need to dynamically 
    	allocate IP addresses through IPsec tunnels.  Long email with
    	will be forwarded to the list shortly.  This removes the
    	and significantly reduces interoperability concerns in this area,
    	removing the last major obstacle to requiring tunnel mode.
    	Summary of proposed requirements for tunnel and transport mode:
    	- Tunnel mode would be REQUIRED in all cases for interoperability.
    	- RFC 2401 classifies every IPsec implementation as either a host
    		or security gateway; Transport mode would also be REQUIRED
    		for host IPsec implementations.  This condition is *solely*
    		about IPsec implementations - it is in principle possible to
    		use a security gateway in conjunction with any iSCSI, FCIP,
    		or iFCP system, even to the point of integrating the gateway
    		onto an HBA or NIC.
    	More details below.
    - Tunnel mode address usage.  Configuration and discovery can be painful
    	if the inner and outer IP addresses are different.  There are no
    	solutions to this in the current IPsec world beyond manual
    	Query to list on this topic coming shortly.
    Detailed minutes:
    We got into a discussion of the -07 draft, posted in December. The
    changes were relatively minor from -06; major difference was the attempt
    to be more general by referring to "IP storage protocols" when text
    intends to apply to iSCSI, FCIP and iFCP. That way, if a new IP storage
    protocol comes along it will be covered and we won't have to revise the
    draft again. Participants were urged to read over the -07 drafts and send
    any issues to the iSCSI security list and/or the IPS WG list. 
    We then talked about IKE identity payloads. David Black noted that the
    current text requires use of IP addresses as identifiers. This is limiting
    because if the addresses are dynamically assigned you will effectively be
    requiring group pre-shared keys, which was what we were trying to avoid by
    favoring aggressive mode for pre-shared keys. 
    The solution is to change the text to also enable use of FQDNs as
    identifiers. There was discussion about whether other ID payloads would
    also be acceptable. This depends on whether we are talking about transport
    mode or tunnel mode. For transport mode, IP subnets or ranges doesn't make
    sense; it might make sense for tunnel mode. It was resolved that Bernard
    will consolidate the text relating to ID payloads and make a proposal to
    the list on how it should be changed, so that we can make progress. 
    We then got into a discussion of IPsec and authorization. In our
    discussion of SLPv2 security as part of the IPS security effort, we had
    gotten into a discussion of whether IPsec could be used for SLPv2
    security, instead of the RFC2608 security. We decided this was ok, and
    Erik Guttman subsequently incorporated IPsec into the RFC2608bis security
    model, removing the previous model. This has caused some discussion about
    how authorization is done. For example, how do you know that a host is
    authorized to act as SA? DA? 
    David noted that with FQDN identifiers, an iSCSI target might be
    configured with a list of authorized FQDNs. Assuming that IPsec
    authentication was successful, this list of FQDNs could be examined to
    determine Initiator authorization. IPsec is also capable of doing some
    basic authentication, by configuring Initiators and Targets with the
    appropriate trusted roots. The trusted root for IPS protocols might be
    different from trusted roots for other purposes. The implication here is
    that IPsec is really most appropriate for intra-domain use -- as has been
    pointed out by the IESG. 
    Looked at the other way, an Initiator doing iSCSI logon authentication via
    a mutually authenticating method (e.g. SRP) would know whether a Target
    was authenticated or not. David Black pointed out that with CHAP the
    Target is not authenticated, only the Initiator, so you might not always
    know that. 
    It is also possible for iSNS to supply authorization information, which
    can make the process of maintaining this more scalable. Text will be
    drafted describing how authorization could be accomplished: via iSNS,
    manually, etc. 
    It was noted that since RFC2608bis now incorporates the IPsec security
    text, that we can probably remove the text from the IPS security draft and
    just reference RFC2608bis, assuming it goes through. This seems cleaner
    and less likely to result in conflicts down the road. 
    We had a short discussion of IPsec certificate handling. It was noted that
    PKIX is going to be working on this -- but that they have traditionally
    been slow at completing things. We talked a bit about the IKE cert
    fragmentation problem. Hillarie Orman's draft on key sizes implies a
    2048bit key recommendation for use with AES. The larger key sizes in turn
    imply larger certs, particularly if OIDs are added. This means that an IKE
    certificate chain will almost certainly cause fragmentation, and even a
    single cert may get close to causing IKE fragmentation. 
    IKE fragmentation is a problem because most NATs will drop fragments as
    will many routers (recent versions of Cisco IOS can handle this
    correctly). David Black requested that we insert a warning describing the
    problem. Unfortunately it is a nasty one because it doesn't really have a
    good solution in the current version of IKE. 
    There was a discussion of dangling IKE Phase 2 SAs. These are not
    prohibited in RFC 2401-2409, and some implementations have them. Yet the
    IPS security draft prohibits them. This text should probably be removed --
    delete the section discussion how IKE phase 2 SAs should be deleted on
    receipt of an IKE phase 1 delete. Bernard took this as an action item. 
    There was a discussion of IKE rekey intervals. The Bellare et al. paper is
    really about the birthday attack problem. That is, since CBC modes depend
    on the previous ciphertext block, if two ciphertext blocks are identical
    and the next plaintext block is also identical then the next ciphertext
    block is also identical. This allows an attacker to find areas of
    repetition within the plaintext. 
    A single birthday attack instance is expected to occur in 2^(X/2) blocks,
    where X is the block size in bits. Probabilities for birthday attack
    occurrence are easily calculated via combinatorics. 
    The current draft text is extremely conservative in that it requests that
    rekey occur in considerably less than 2^(X/2) blocks. This seems excessive
    in that even a single birthday attack instance doesn't leak much
    information -- you just know that two plaintext blocks are the same. To
    get more information you'd need quite a few birthday attack instances,
    which is very unlikely in just 2^(X/2) blocks.  So the proposal is to
    redo the calculations using the 2^(X/2) formula. David Black requested
    some explanation of the issue as well. 
    We also talked about the status of ESPv3. This is currently non-normative
    (not required by IP Storage protocols), and David Black requested that it
    stay that way unless it was in IPsec WG last call by IETF 54 in Yokahama,
    We talked about iSNS security policy. The goal of the IPS security
    document is to specify IPsec parameters well enough so that
    implementations will be able to negotiate things and interoperate off the
    bat. As a result, the minimum piece of configuration required is whether
    an IPS endpoint requires IPsec or cleartext. This can't be determined from
    IKE alone without risking a long timeout, something undesirable for a disk
    access protocol. 
    The information can be configured manually, or can be supplied via
    iSNS. If an Initiator can obtain IPsec security policy from other means
    (manually, via IPsec security policy functionality) then it need not query
    the iSNS server for this information. However, if it doesn't have the
    information, it can use iSNS to obtain an IKE proposal payload for a
    particular Target. 
    The question was asked about what security configuration information
    could/should be provided by SLPv2. The minimum configuration would be an
    SLPv2 attribute describing whether a Target supports IPsec. 
    It was noted that if iSNS or SLPv2 is used to determine security policy or
    configuration, then these protocols MUST be secured. Otherwise, an
    attacker could provide bogus security policy to convince a host to connect
    to it in cleartext. Authorization is important too, or else an attacker
    who had an IPsec certificate could masquerade as an iSNS server or SLPv2
    DA and provide bogus information. 
    We then got into a discussion of tunnel mode vs. transport mode. David
    Black noted that in many situations, IPS gateways are not functioning as
    IPsec gateways or an IP router. Thus, the IPS gateway will not routing
    packets through it -- both the inner and outer tunnel addresses will be
    consumed by the IPS gateway. 
    As a result, the IPS gateway will not need to assign addresses for use
    with IPsec tunnel mode. This simplifies things considerably. 
    It was resolved that Bernard would put together text explaining the
    various configurations and the implications, based on David's original
    message on the subject. 
    With respect to the IPsec tunnel mode vs. transport mode debate, David
    proposed the following: IPsec tunnel mode is a MUST implement for both
    Initiators and Targets; IPsec transport mode is also required where
    RFC2401 says it is required. 
    RFC 2401 requires Transport mode for everything but IPsec gateways. 
    The end result of this is that a Target might be able to just implement
    Tunnel mode if it were to act as an IPsec gateway; however, if it is not a
    gateway, then it MUST implement transport mode.
    For the specific case of an iSCSI initiator, only tunnel mode would
    be "MUST implement", as that is the minimum requirement for
    If an initiator's IPsec implementation is an IPsec gateway (as RFC 2401
    defines and uses that term), then it would not be required to implement
    transport mode.
    The question was raised of whether having to do both transport and tunnel
    was excessive. Would this be a problem for hardware vendors?  David
    Black felt that this approach seemed like the only way to satisfy both
    those vendors who want to enable separate gateway boxes as well as those
    who prefer the efficiency and end to end approach of IPsec transport mode.
    Existing IPsec implementations conform to RFC 2401, and hence this
    (transport mode required where RFC 2401 says it is required) should not
    problems for use of such implementations.  Finally, David felt that not
    only was adhering to this aspect of the IPsec architecture a good thing to
    do in principle, but in practice it should also help avoid Last Call
    objections that iSCSI is misusing IPsec by departing from the architecture.
    In connection with the latter point, a question was raised about whether
    not requiring AH could cause difficulties.  It will not, because the
    ipsec WG is in the process of revising RFC 2401 to (among other
    things) remove the current requirement for AH.
    Sorry for the delay in getting these out.
    David L. Black, Senior Technologist
    EMC Corporation, 42 South St., Hopkinton, MA  01748
    +1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500         Cell: +1 (978) 394-7754


Last updated: Fri Feb 01 13:17:55 2002
8595 messages in chronological order