Survey and Taxonomy of Key Management Protocols for Wired and Wireless Networks

ABSTRACT Number of keys used to convert plaintext to ciphertext. For example, symmetric/single or asymmetric/two key/public key. Key is an element which can be either numeric or non-numeric, which when applied to a given message results in a encrypted message. Key can be implicitly or explicitly derived from plaintext. Implicit key derivation is also known as auto keying, where the derived key is a part of the plaintext. Explicit key or individual key is a key that is not a part of the plaintext. For a secure communication to take place, the life cycle of key involves: initialization, agreement, distribution and cancellation. This entire process is also known as key management

Design and Validation of Automated Authentication, Key and Adjacency Management for Routing Protocols

To build secure network-based systems, it is important to ensure the authenticity and integrity of the inter-router control message exchanges. Authenticating neighbors and ensuring their legitimacy is essential. Otherwise, the routes installed could be erroneous or targeted at causing an attack on the system. Current methods, which are based on manual keying, are error prone, not scalable, and result in keys being changed infrequently (or not at all) due to lack of authorized personnel. These issues can be addressed only by having an automated key management system that can automatically generate, distribute and update keys. The issue can be cast as a group key management problem with a `keying group' defined as the set of all routers that share the same key. A keying group can be as large as an entire administrative domain, or as small as a pair of peer routers. The smaller the scope of the key the less damaging the loss of a single key is likely to be. In this thesis, we propose an automated key management system that will be able to handle different categories of keying groups and also ensure important properties such as adjacency management, protection against replay attacks, confidentiality of messages, smooth key rollover, and robustness across reboots. Although there is some ongoing work with regard to developing automated key management systems, none of the existing methods handles all these cases. We have formally validated the protocol designed, for essential security properties such as authentication, confidentiality, integrity and replay protection, using a formal validation tool called AVISPA

Junos OS Security Configuration Guide

This preface provides the following guidelines for using the Junos OS Security Configuration Guide: • J Series and SRX Series Documentation and Release Notes on page xli • Objectives on page xlii • Audience on page xlii • Supported Routing Platforms on page xlii • Document Conventions on page xlii • Documentation Feedback on page xliv • Requesting Technical Support on page xliv Juniper Networks supports a technical book program to publish books by Juniper Networks engineers and subject matter experts with book publishers around the world. These books go beyond the technical documentation to explore the nuances of network architecture, deployment, and administration using the Junos operating system (Junos OS) and Juniper Networks devices. In addition, the Juniper Networks Technical Library, published in conjunction with O'Reilly Media, explores improving network security, reliability, and availability using Junos OS configuration techniques. All the books are for sale at technical bookstores and book outlets around the world. The current list can be viewed at http://www.juniper.net/books .Junos OS for SRX Series Services Gateways integrates the world-class network security and routing capabilities of Juniper Networks. Junos OS includes a wide range of packet-based filtering, class-of-service (CoS) classifiers, and traffic-shaping features as well as a rich, extensive set of flow-based security features including policies, screens, network address translation (NAT), and other flow-based services. Traffic that enters and exits services gateway is processed according to features you configure, such as packet filters, security policies, and screens. For example, the software can determine: • Whether the packet is allowed into the device • Which firewall screens to apply to the packet • The route the packet takes to reach its destination • Which CoS to apply to the packet, if any • Whether to apply NAT to translate the packet’s IP address • Whether the packet requires an Application Layer Gateway (ALG