1 / 6

GDOI Changes to Update Draft

GDOI Changes to Update Draft. draft-ietf-msec-gdoi-update-01 Sheela Rowles Brian Weis. Changes since Montreal IETF. Address GDOI Attack. GCKS Authorization. Mitigation of attack by Meadows & Pavlovic if GCKS performs authorization based on IKEv1 credentials.

anitat
Download Presentation

GDOI Changes to Update Draft

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. GDOI Changes to Update Draft draft-ietf-msec-gdoi-update-01 Sheela Rowles Brian Weis

  2. Changes since Montreal IETF • Address GDOI Attack

  3. GCKS Authorization • Mitigation of attack by Meadows & Pavlovic if GCKS performs authorization based on IKEv1 credentials. • A rogue device can perpetrate a man-in-the-middle attack if the following conditions are true: • The rogue GDOI participant convinces an authorized member of the group (i.e., victim group member) that it is a key server for that group. • The victim group member, victim GCKS, and rogue group member all share IKEv1 authentication credentials. • The victim GCKS does not properly verify that the IKEv1 authentication credentials used to protect a GROUPKEY-PULL protocol are authorized to join the group.

  4. GCKS Authorization (cont.) Attack Mitigations: • A GDOI group member SHOULD be configured with policy describing which IKEv1 identities are authorized to act as GCKS for a group. • A GDOI key server SHOULD perform one of the following authorization checks. • No CERT/POP: the GCKS SHOULD maintain a list of authorized group members for each group, where the group member identity is its IKEv1 authentication credentials. • Yes CERT/POP: the GCKS SHOULD verify that the identity in the CERT payload refers to the same identity in the IKEv1 authentication credentials.

  5. POP Definition • Point of POP is to prove that the Phase 1 Key Identity is the same as the owner of the key distributed in the CERT.

  6. POP Change Original RFC: POP_HASH = hash(“pop”| Ni | Nr) Intended since Montreal IETF: POP_HASH = hash(“pop” | SKEYID_A | Ni | Nr) Finally: POP_HASH = hash(“pop” | IKE-INIT-PH1-ID | IKE-RESP-PH1-ID | Ni | Nr)

More Related