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 _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
