GDOI Update

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. Dont 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 --gt
• lt-- HDR, HASH(2), Nr,
  SA
• HDR, HASH(3) ,KE_I --gt
• ,CERT ,POP_I
• lt-- HDR,
  HASH(4),KE_R,SEQ,
• KD
  ,CERT,POP_R
• This results in a DH shared secret
• The DH shared secret is xored with the data
  per the Oakley IEXTKEY procedure.
• But Oakley uses IEXTKEY to xor the secret with
  a key, not a payload. Clearly there arent 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?