Subject: [MSEC] Fwd: Proposed updates to GDOI draft

From: Mark Baugher <[email-masked]>
Date: Wed, 04 Jul 2001 09:53:33 -0700

Brian did not intend for his note to be forwarded to msec, but I think he 
did a good job of pre-editing the next version of the GDOI document and I 
thought it would be helpful to msec to see what we are doing with the next 
GDOI I-D.  I don't think Brian will mind me doing this.  Since he's on 
vacation, I volunteered to edit the document.  There will probably need to 
be a telecon among Hugh, Thomas and me to finalize this revision.  So my 
remarks are for them, first and foremost.  I'll list every issue and what I 
propose to do with it since some issues are controversial, we will need to 
postpone the update until after Brian returns.  I have a couple of issues 
to add.  Note that Brian appended an edited version of the I-D but I 
removed the appendage from this note because it is quite long.  Here are 
Brian's issues:

1. ISSUE 1: I agree that we make this change.
2. ISSUE 2: ditto
3. ISSUE 3: I don't understand this since we need some value for 
interoperability testing.
4. ISSUE 4: I agree that we make this change
5. ISSUE 5: I think we should discuss this after the IETF meeting
6. ISSUE 6: I agree wholeheartedly that we always match the Phase 2 DOI the 
Phase 1
7. ISSUE 7:  I agree
8. ISSUE 8: I personally disagree and want to discuss after the IETF meeting
9. ISSUE 9: Thomas, your contact information, please
10. ISSUE 10: I disagree and want to discuss after the IETF meeting
11. ISSUE 11: I strongly disagree and want to discuss after the IETF meeting

The other issues that I have are with the front-matter of GDOI revision 00: 
I think we should remove everything that is redundant to 
draft-ietf-msec-gkmarch-00.txt and refer to this draft for the model we are 
using.

Mark

>Sender: [email-masked]
>Date: Sat, 30 Jun 2001 11:26:58 -0700
>From: Brian Weis <[email-masked]>
>X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686)
>X-Accept-Language: en
>To: [email-masked], Hugh Harney <[email-masked]>,
>         Thomas Hardjono <[email-masked]>
>Subject: Proposed updates to GDOI draft
>
>Greetings, fellow GDOI draft authors.
>
>We're about 3 weeks away from the final ID submission date for the
>London
>IETF. There are a number of issues which should be dealt with so that we
>can
>submit a -01 version of GDOI for London.
>
>Having said that, I begin a 2 week vacation on Monday, and won't be in a
>location where there is easy Internet access, so I may miss most of the
>discussion. :-( I will listen to voice mail occasionally, and will
>return phone
>calls as best I can. But this is rural N.D., and even though the
>telephone
>switches have been upgraded from rotary-only, one is still not
>guaranteed to
>have a touch tone phone available in the house. :-)
>
>I apologize in advance for not starting this discussion earlier.
>However, I have enclosed a list of issues that I've kept since the
>last IETF, along with proposed resolutions and text. Also, for
>convenience
>I've attached a text version of -00 with these changes so you can see
>them
>inline. Please comment on them, tear my logic and text apart as you
>will, etc.
>
>Please introduce new issues to the discussion as you see fit. Mark has
>kindly
>agreed to edit the document in my absence.
>
>I propose that we do not attempt to harmonize with the new GKM Arch.
>document
>until after the London meeting, since it appears to be a bit
>controversial.
>
>If you all come to agreement before my return and feel the need to
>submit the
>-01 draft,  please do so. Otherwise, I return on 7/16 and will have
>until 7/20
>to submit it. It will be on the top of my priority list.
>
>Thanks,
>Brian
>
>ISSUE 1
>-------
>Section 5.4. The SA_TEK payload doesn't really need RESERVED (3) for
>alignment. The next field isn't aligned anyway due to the free-form
>length of
>the ID (which is usually 4 bytes, putting the starting point at the 2nd
>byte
>of the word). I propose replacing the current bitmap diagram with this:
>
>======== BEGIN TEXT
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
>     ! Next Payload  !   RESERVED    !         Payload Length        !
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
>     ! Protocol-ID   !       TEK Protocol-Specific Payload           ~
>     +-+-+-+-+-+-+-+-+                                               ~
>     ~                                                               ~
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
>======== END TEXT
>
>ISSUE 2
>-------
>Format of keys in the KD payload is under-specified, for both encryption
>keys
>and authentication keys. For example, there could be questions as to
>whether
>the keys sent bitwise or in an ASCII representation of them, and in the
>case
>of DES are parity bits included or not. The following sections attempt
>to
>address these ambiguities.
>
>For section 5.5.1.1 (encryption keys):
>
>======== BEGIN TEXT
>DES keys will consist of 64 bits (the 56 key bits with parity bits).
>Triple DES
>keys will be be specified as 64 bit keys  in the order that they are to
>be used
>for encryption (e.g., DES_KEY1, DES_KEY2, DES_KEY3).
>======== END TEXT
>
>Similarly, in section 5.5.1.3 (authentication keys):
>
>======== BEGIN TEXT
>SHA keys will consist of 160 bits, and MD5 keys will consist of 128
>bits.
>======== END TEXT
>
>ISSUE 3
>-------
>There's a problem with the DOI number in Section 5.2. It is currently
>specified thusly:
>
> > o DOI (4 octets) - Is the GDOI, which is value 196 pending
> > assignment by the IANA.
>
>We've chosen a value for our DOI, but in fact we should not be
>choosing numbers until IANA assigns us one. Thus should say
>
>======== BEGIN TEXT
>    o DOI (4 octets) -  TBD pending assignment by the IANA.
>======== END TEXT
>
>But IANA won't assign us one until we are further along in the standards
>process. We have to choose something in the meantime for interop
>testing.
>
>The right way to do that is to define a new vendor-id payload as part of
>Phase 1 which specifies a local context in which to interpret
>non-assigned
>numbers.  I proposed we delay that until the next draft version. Or, we
>can
>model one after the XAUTH draft now, if you feel it should be done
>for this draft.
>
>ISSUE 4
>-------
>Regarding this semantic of the KD payload in section 5.5:
>
> > If the "Number of Key Packets" is zero, the group member is expected to
> > delete all keys associated with the ID. This type of KD payload will
> > only be sent by the GCKS when a group is deleted.
>
>Early on we discussed replacing the following semantic with an IKE
>Delete
>payload. I would like to do that now. I don't really like having an
>implicit
>semantic to delete keys; it might be efficient, but it's prone to both
>specification and implementation error. The Delete payload is defined in
>RFC 2408 section 3.15, and basically sends a list of SPIs to delete.
>
>I propose removing the text above, and adding a section 4.5.
>
>======== BEGIN TEXT
>4.5 Deletion of SAs
>
>There are times the GCKS may want to signal to receivers to delete SAs,
>for
>example at the end of a broadcast when no more data will be sent to the
>group.
>Deletion of keys may be accomplished by sending an ISAKMP Delete payload
>as
>part of a GDOI GROUPKEY-PUSH message.
>======== END TEXT
>
>ISSUE 5
>-------
>If no KEK is defined, then the SEQ payload is not needed. Today a group
>which
>doesn't use a KEK is forced to carry the SEQ as unnecessary baggage.
>
>This could be fixed by making the SEQ payload optional. But then the
>implementation has to keep track of whether it needs to send it or not
>(i.e.,
>if it's sending a KEK). Note that the HASH(4) is also changed slightly
>if SEQ
>is made optional, but HASH(4) already has some optional payloads in it.
>
>If you believe the extra complexity is worth adding in order to make the
>non-KEK case correct, I propose modifying the exchange thusly:
>
>======== BEGIN TEXT
>         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]
>Hashes are computed as follows:
>     HASH(1) = prf(SKEYID_a, M-ID | Ni | ID)
>     HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA)
>     HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_I ] [ | POP_I ])
>     HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_R ] [ | SEQ ] |
>KD
>                [ | POP_R])
>======== END TEXT
>
>ISSUE 6
>-------
>In section 2.4 it should be mentioned that if GDOI sets up the IKE Phase
>1,
>that the DOI in the IKE Phase 1 SA payload should be the GDOI value (not
>the
>IPSEC value). I've added the following new sub-section to declare this.
>
>======== BEGIN TEXT
>
>2.4.1 IKE Phase 1 SA Payload
>
>The IKE Phase 1 SA payload has a DOI value. That value should be the
>GDOI DOI
>value as defined later in this document.
>======== END TEXT
>
>ISSUE 7
>-------
>In section 5.4 the Protocol-ID field for the TEK payload is currently
>defined
>based on the IPSec protocol list (e.g., PROTO_IPSEC_ESP is 4 which
>matches
>RFC 2407).  However, as we want to support other non-IPSec protocols we
>can't
>re-use the address space. I propose replacing the existing list with the
>following new set of identifiers:
>
>======== BEGIN TEXT
>        Protocol ID                       Value
>        -----------                       -----
>        RESERVED                            0
>        GDOI_PROTO_IPSEC_ESP                1
>        GDOI_PROTO_MESP                     2
>        GDOI_PROTO_AMESP                    3
>        GDOI_PROTO_SRTP                     4
>        RESERVED                          5-127
>        PRIVATE USE                     128-255
>======== END TEXT
>
>ISSUE 8
>-------
>Steve Kent pointed out at the last IETF that  Attribute Certs don't have
>a
>pubkey in them, so by extension the GROUPKEY-PULL exchange doesn't need
>the
>POP payload to go with the CERT. I see the following alternatives:
>     a. Remove the POP. This requires the keypair used for authentication
>to be
>        used for authorization, which is a certain limitation.
>     b. Require the authorization keypair to be separate. This requires
>us to
>        extend the (CERT, POP) pair in the exchange to be a triple
>        (AUTHENT_CERT, AUTHOR_CERT, POP) where the AUTHENT_CERT carries
>the
>        pubkey associated with the private key used to sign the POP, and
>        AUTHOR_CERT is the attribute cert. That's quite a lot of
>overhead!
>     c. Combine the whole mess into a new AUTH payload which can be
>defined in
>        many ways. This would also allow other methods of authorization
>which
>        are not public key based (e.g., send a user entered PIN).
>
>I favor c. It would modify the GROUPKEY-PULL exchange like this:
>
>======== BEGIN TEXT
>         Initiator (Member)                   Responder (GCKS)
>         ------------------                   ----------------
>         HDR*, HASH(1), Ni, ID     -->
>                                   <--     HDR*, HASH(2), Nr, SA
>         HDR*, HASH(3) [, KE_I]    -->
>            [,AUTHOR]
>                                   <--     HDR*, HASH(4), [KE_R,] [SEQ,]
>                                             KD [,AUTHOR]
>Hashes are computed as follows:
>     HASH(1) = prf(SKEYID_a, M-ID | Ni | ID)
>     HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA)
>     HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_I ] [ | AUTHOR ])
>     HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_R ] [ | SEQ ] |
>KD
>                [ | AUTHOR])
>* Protected by IKE Phase 1 SA, encryption occurs after HDR
>======== END TEXT
>
>The following text defining the Authorization payload replaces section
>5.7 "Proof of Possession" which would be no longer needed. (There are
>other
>edits needed to to remove the POP throughout the document, but I'll omit
>those
>until there's agreement that this is the right approach.)
>
>NOTE: I didn't include a SPKI variety of authorization cert because I
>think
>the authorization is bound in the authentication certificate, so no
>separate
>AUTHOR cert would be needed. If that is wrong, please add that type and
>some
>appropriate text.
>
>======== BEGIN TEXT
>5.7 Authorization Payload
>
>The Authorization Payload (AUTHOR) provides an authorization mechanism
>for the
>GCKS to verify that a group member is authorized to join a group. It is
>also
>used by a group member to verify that a GCKS is authorized to serve keys
>for a
>group.
>
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
>   ! Next Payload  !   RESERVED    !         Payload Length        !
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   ! Auth Type     !           Authorization Payload               ~
>   +-+-+-+-+-+-+-+-+                                               ~
>   ~                                                               ~
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
>
>  The Authorization Payload fields are defined as follows:
>
>     o Next Payload (1 octet) - Identifier for the payload type of the
>next payload in the message.  If the current payload is the last in the
>message, then this field will be zero.
>
>     o  RESERVED (1 octet) - Unused, set to zero.
>
>     o  Payload Length (2 octets) - Length in octets of the current
>payload, including the generic payload header.
>
>     o Auth Type (1 octet) - This field defines the type of authorization
>which
>is to be used for the group.
>
>              Auth Type               Value
>              ---------               -----
>              X.509_ATTRIBUTE_CERT      1
>              PASSWORD                  2
>              RESERVED                3-127
>              Private Use           128-255
>
>     o Authorization Payload (varies) - The actual authorization data.
>The
>following sections define those payloads by type.
>
>5.7.1 X.509_ATTRIBUTE_CERT
>
>The authorization payload contains the Attribute Certificate as defined
>in [FH]
>[NOTE: reference points to draft-ietf-pkix-ac509prof-06.txt].
>
>The Attribute Certification must have a critical extension which
>declares the group id (format TBD).
>
>5.7.1 PASSWORD
>
>The authorization payload contains the following structure:
>
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
>   ! Length                          !      Password               ~
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                             ~
>   ~                                                               ~
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
>
>The password field structure is defined as follows:
>
>     o Length (2 octets) - Length of the password.
>
>     o Password (variable) - Password Data
>======== END TEXT
>
>ISSUE 9
>-------
>Thomas needs to fill in his new contact info. I've start it so it won't
>be
>forgotten.
>
>ISSUE 10
>--------
>Dan Harkins was adamant that we don't use the IKE port for GDOI. I
>propose the following section to address that.
>
>======== BEGIN TEXT
>2.4.2 GDOI Port
>
>In order to enable separation of protocol state machines, GDOI should
>not use
>the port commonly used by IKE (udp port 500). A port must be assigned by
>IANA.
>======== END TEXT
>
>ISSUE 11
>--------
>There are two issue with section 3.2.1 (Perfect Forward Secrecy). I
>think it
>is easiest to consider them separately.
>
>    a. There is some confusion in the naming, as to whether the function
>       provided by KE payloads is "perfect forward secrecy" or "perfect
>       backwards secrecy". This should get sorted out. The intended
>property
>       of KE payloads is that if someone discovers the current IKE
>protocol
>       keys (e.g., through cryptanalysis), they should not be able to
>       automatically get the next set of keys (in this case, the keys
>which are
>       used to protect the TEK and KEK keys in the KD payload).
>
>       If you can sort out the proper term, please fix the section to use
>the
>       appropriate nomenclature.
>
>    b. There is some disagreement as to why we would need KE payloads at
>all. I
>       believe we need them, and propose the following rationale to be
>inserted
>       at the beginning of section 3.2.1 (before the current paragraph).
>
>======== BEGIN TEXT
>PFS may be necessary in some scenarios. The GROUPKEY-PULL exchange is
>protected by the IKE Phase 1 encryption keys, as is the IKE Phase 2
>exchange.
>It should be noted that in the case of the IKE Phase 2 exchange, no keys
>are
>ever passed in the exchange -- they are always derived from keying
>material that has some secret component (e.g., from a previous DH
>exchange).
>However, the IPSec working group still saw it necessary that there
>should be a
>mechanism for refreshing the hidden keying material (through use of the
>KE
>payloads).
>
>With PFS protection, the risk to the KEK and TEK keys is far greater for
>the
>GDOI GROUPKEY-PULL exchange. The keys are passed directly from the GCKS
>to the
>group member in the KD payload. A passive attacker can store GDOI
>GROUPKEY-PULL
>packets as well as the data packets and attempt to break the IKE Phase 1
>encryption keys.  Once that is done, the attacker has direct access to
>the KEK
>and TEK keys stored in the KD payload and can then decrypt the stored
>content
>for as long as the discovered KEK key is used.
>
>Use of the KD payloads complicates this attack by causing the attacker
>to
>perform further cryptanalysis to determine the keying derived from the
>KD
>payload."
>======== END TEXT
>
>ISSUE 12
>--------
>Mark has developed an Appendix which describes how to pass SRTP policy
>in
>GDOI, just as Appendix A describes how to pass MESP/AMESP policy in
>GDOI.
>This should be added to this draft.
>

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec

---

From: Mark Baugher <[email-masked]>
Date: Thu, 05 Jul 2001 20:08:50 -0700

Thomas, Hugh, Brian

I updated the draft and put an interim version on the web for your 
review.  I made the changes that I said I would make in the appended 
note:  Issues 1, 2, 4, 6, 7, and 9 were added and text was removed that was 
redundant or inconsistent with the GKM architecture I-D.  Issues 3, 5, 8, 
10, and 11 remain to be updated.  I'm okay with formatting this version for 
submission next week.  The rough-draft text version is at
http://www.rdrop.com/users/mbaugher/draft-ietf-msec-gdoi-01v2.txt
And the pdf version that highlights the changes are at
http://www.rdrop.com/users/mbaugher/draft-ietf-msec-gdoi-01v2.pdf

Let me know what you think no later than next Monday.  I'm travelling on 
Tuesday and Wednesday.  I plan to submit the draft on Thursday.

Mark
>Date: Wed, 04 Jul 2001 09:53:33 -0700
>To: [email-masked], [email-masked], Brian Weis <[email-masked]>
>From: Mark Baugher <[email-masked]>
>Subject: Fwd: Proposed updates to GDOI draft
>Cc: [email-masked]
>
>remarks are for them, first and foremost.  I'll list every issue and what 
>I propose to do with it since some issues are controversial, we will need 
>to postpone the update until after Brian returns.  I have a couple of 
>issues to add.  Note that Brian appended an edited version of the I-D but 
>I removed the appendage from this note because it is quite long.  Here are 
>Brian's issues:
>
>6. ISSUE 6: I agree wholeheartedly that we always match the Phase 2 DOI 
>the Phase 1
>7. ISSUE 7:  I agree
>The other issues that I have are with the front-matter of GDOI revision 
>00: I think we should remove everything that is redundant to 
>draft-ietf-msec-gkmarch-00.txt and refer to this draft for the model we 
>are using.
>
>Mark
>
>>Sender: [email-masked]