[rrg] [ILNP] Firewalls and good practices

[RJ Atkinson <[e-mail]>]

Earlier, Stephane Bortzmeyer quoted this text:
>> "The use of Identifiers enables firewalls to have access
>> control rules that are based on identity, rather than address or
>> location. This might permit a corporate IT security manager to give
>> the CEO's laptop more privileges than a network-capable ID badge
>> reader, for example." 

In the same note, Stephane Bortzmeyer commented:
> This claim is not reproduced in the current set of I-D and rightly so:
> because ILNP has no protection of the Identifier (such as ORCHID),
> it is easy to lie about your Identifier.

It is straight-forward to authenticate the Identifier/packet binding.

1) ILNP does support use of cryptographically-generated identifiers
   using the same mechanisms as have been specified for IPv6
   Cryptographically-Generated Addresses (CGAs).  For example,
   the mechanism in RFC-3972 can be used with ILNPv6.  If one
   has a SEND implementation deployed, it also should be possible 
   to use this with ILNPv6 as ND is not changed by ILNPv6.

2) Separately, the current set of I-Ds clearly specify how IPsec 
   can be used with ILNP and also specify how ILNP IPsec differs 
   from classic IPsec.  In turn, ILNP IPsec AH can be used to 
   cryptographically authenticate the binding of a particular 
   Identifier value with a particular ILNP packet.  Separate 
   IETF work is underway to enable IPsec-related public key
   information to be stored in the DNS.  Existing IETF standards
   specify DNS Security.  DNSsec implementations are readily
   available now (e.g. BIND, others).  DNSsec deployments in 
   the global Internet appear to be growing rapidly.

   So it is straight-forward to cryptographically authenticate 
   the Identifier value in a packet in an operational situation
   where that might be desirable.

   Situations where a firewall (or other security gateway) would
   examine a packet and authenticate the identifier(s) present
   in that packet (whether an IP address or an ILNP Identifier
   or something else) generally fall into the category of
   Intermediate Network Authentication -- since the security
   gateway is not one of the endpoints in the communications
   session.

   Some approaches to Intermediate Network Authentication, 
   including the use of AH with an asymmetric digital signature, 
   are covered by US Patent 5,511,122.  This patent's existence 
   has been disclosed, more than once, to the IETF, including 
   a disclosure to the IETF IPsec WG mailing list back in 1996.  
   The inventor on that patent has not been involved in any 
   IETF work specifying use of AH with asymmetric digital 
   signatures (e.g. RFC-4359).

While I believe the quoted text at very top (i.e, about ILNP 
enabling identity-based authorisation/access-control) is still 
correct, it did not seem essential to document that optional 
capability as part of the current ILNP protocol specifications, 
while adding that description to the current ILNP protocol 
documents would have added procedural complexity to the 
publication process for the ILNP document set (e.g. due to 
IPR considerations).

Yours,

Ran