1 / 14

GDOI Update

GDOI Update. draft-weis-gdoi-update-00 Sheela Rowles Brian Weis. Purpose of this draft. Algorithm Agility Clarifications Address vulnerability. Algorithm Agility. Support SHA-256 as alternative to SHA-1 and MD5: replace SHA-1 due to recent published attacks. Algorithm Agility (cont).

chessa
Download Presentation

GDOI Update

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 Update draft-weis-gdoi-update-00 Sheela Rowles Brian Weis

  2. Purpose of this draft • Algorithm Agility • Clarifications • Address vulnerability

  3. Algorithm Agility • Support SHA-256 as alternative to SHA-1 and MD5: replace SHA-1 due to recent published attacks

  4. Algorithm Agility (cont) • GROUPKEY-PULL: Hash algorithms are the same as for IKEv1, where SHA-256 HASH is included in the IKE IANA assignments • Groupkey-PUSH: Add SHA-256 algorithm to the SIG_HASH_ALGORITHM attribute.

  5. Algorithm Agility (cont) • GDOI distributes IPSec ESP SAs • HMAC-SHA2-256 specifies SHA-256 • GDOI (as of this update) distributes IPSec AH SAs • HMAC-SHA2-256 can be chosen

  6. RFC 3547 ClarificationsSA payload • SIG_KEY_LENGTH unit is bits not bytes • RFC mentions that an IV must be sent in the KEK_ALGORITHM_KEY attribute. This update clarifies that the IV length should not be included in the KEK_KEY_LEN attribute. • KEK_KEY_LEN attribute is optional. Don’t need this attribute if cipher definition includes a fixed key length.

  7. Clarifications (cont)SIG/SEQ Payload • Clarify ambiguous wording in creation of the SIG payload • SEQ Payload Clarifications • GDOI-GROUPKEY-PULL SEQ always 0 • GDOI-GROUPKEY-PUSH SEQ starts with 1 • GDOI-GROUPKEY-PUSH SEQ resets to 1 with a new KEK attribute.

  8. ClarificationsPOP Payload • POP Hash Algorithm MUST be the same as the HASH Alg used in SIG_HASH_ALGORITHM due to omission in the RFC.

  9. ClarificationsPFS • RFC 3547 exchanges KE payloads fo PFS Initiator (Member) Responder (GCKS) ------------------ ---------------- HDR*, HASH(1), Ni, ID --> <-- HDR*, HASH(2), Nr, SA HDR*, HASH(3) [,KE_I] --> [,CERT] [,POP_I] <-- HDR*, HASH(4),[KE_R,][SEQ,] KD [,CERT][,POP_R] • This results in a DH shared secret • The DH shared secret is “xor”ed with the data per the Oakley IEXTKEY procedure. • But Oakley uses IEXTKEY to “xor” the secret with a key, not a payload. Clearly there aren’t always enough DH bits for the entire KD payload!

  10. ClarificationsPFS (cont.) Proposed new algorithm is: • The leftmost bits in the DH shared secret are used as an encryption key. The encryption key algorithm described in the KEK_ALGORITHM attribute is used. • The new key is used to encrypt the KD payload. Note that the length of the KD payload may be larger due to cipher block padding. If so, the KD payload length must be modified to reflect the actual length of the ciphertext.

  11. 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 be join the group.

  12. 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 an 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 identify in the CERT payload refers to the same identity in the IKEv1 authentication credentials.

  13. AH Support • Extend GDOI to support ESP & AH IPSec SAs.

  14. Questions • Should this be a working group draft?

More Related