Internet Security Association and Key Management Protocol (ISAKMP)

Maughan, Douglas; Schertler, Mark; Schneider, Markus; Turner, Jason S.

doi:10.17487/rfc2408

Cited by 277 publications

(144 citation statements)

References 15 publications

Supporting

Mentioning

140

Contrasting

Unclassified

Order By: Relevance

“…o In addition, for all security associations bound to the mobile node's home address established by IKE, the mobile node MUST include an ISAKMP Identification Payload [8] in the IKE phase 2 exchange, giving the mobile node's home address as the initiator of the Security Association [7].…”

Section: Interaction With Outbound Ipsec Processingmentioning

confidence: 99%

Mobility Support in IPv6

Johnson¹,

Perkins²,

Arkko³

2004

2,306

2,236

View full text Add to dashboard Cite

Section: Interaction With Outbound Ipsec Processingmentioning

confidence: 99%

Mobility Support in IPv6

Johnson¹,

Perkins²,

Arkko³

2004

2,306

2,236

View full text Add to dashboard Cite

“…For the replacement of Key N, this new key will be sent encrypted in the newly replaced Key K (for Users 9, 10, and 12) and will also be encrypted in the node key shared by Users 13, 14, 15, and 16 (Key L). For the replacement of Key O, this new key will be sent encrypted in the newly replaced Key N (for Users 9, 10, 12, 13, 14, 15, and 16) and will also be encrypted in the node key shared by Users 1,2 ,3,4,5,6,7,and 8 (Key M).) The number of transmissions required is the sum of the degrees of the replaced nodes.…”

Section: The Exclusion Principlementioning

confidence: 99%

Key Management for Multicast: Issues and Architectures

Wallner¹,

Harder²,

Agee³

1999

801

681

View full text Add to dashboard Cite

This report contains a discussion of the difficult problem of key management for multicast communication sessions. It focuses on two main areas of concern with respect to key management, which are, initializing the multicast group with a common net key and rekeying the multicast group. A rekey may be necessary upon the compromise of a user or for other reasons (e.g., periodic rekey). In particular, this report identifies a technique which allows for secure compromise recovery, while also being robust against collusion of excluded users. This is one important feature of multicast key management which has not been addressed in detail by most other multicast key management proposals [1,2,4]. The benefits of this proposed technique are that it minimizes the number of transmissions required to rekey the multicast group and it imposes minimal storage requirements on the multicast group.

show abstract

“…In this case application level encryption is not sufficient; IPSEC ESP [24] SHOULD be used instead. Regardless of which level performs the encryption, the IPSEC ISAKMP [25] service SHOULD be used for key management. The SCTP Payload Protocol Identifier value "3" SHOULD be included in each SCTP DATA chunk, to indicate that the SCTP is carrying the M3UA protocol.…”

Section: Protecting Confidentialitymentioning

confidence: 99%

“…Thus these extensions are assigned by IANA through an IETF Consensus action as defined in Guidelines for Writing an IANA Considerations Section in RFCs (25] The proposed extension must in no way adversely affect the general working of the protocol. In the example above, each signalling process (SGP, ASP or IPSP) is the end point to more than one SCTP association, leading to more than one other signalling processes.…”

Section: M3ua Protocol Extensionsmentioning

confidence: 99%