Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST LTKM/STKM Transport
draft-dondeti-msec-mikey-genext-oma-04

[Ballot comment]
If draft-narten-iana-considerations-rfc2434bis-05 change the word it currently uses for "IETF Review" this documents IANA section will not make sense and IANA will not know what to do with it. Because of that I think draft-narten-iana-considerations-rfc2434bis-05 should be a normative reference. My recommendation to fix this would instead of using draft-narten-iana-considerations-rfc2434bis-05, instead reference 2434 which has exactly the same thing but calls it something different. Keep in mind, given it is the same thing with a new name, it is not out of the realm of possibility that the works "IETF Review" will change in draft-narten-iana-considerations-rfc2434bis-05 before it becomes an RFC.

I put this as a comment - Russ and IANA can decide if they are willing to make this registration like this.

[Ballot discuss]
From SecDir Review by Sean Turner:

  In the security considerations the document says that if
  confidentiality is required it must be protected "in place".
  It is unclear what "in place" means.

  Expected revision of the Security Considerations to address this
  concern is:

  According to RFC 3830, the general extension payload can be used in
  any MIKEY message and is part of the authenticated/signed data part.
  The parameters proposed to be included in the OMA BCAST MIKEY General
  Extension payload (listed in Section 3) need only to be integrity
  protected, which is already allowed by the MIKEY specification.  The
  OMA BCAST MIKEY General Extension Payload SHALL be integrity
  protected.  Furthermore, keys or any parameters that require
  confidentiality MUST NOT be included in the General Extension
  Payload.  If Keys or other confidential data are to be transported
  via the General Extension Payload, such data MUST be encrypted and
  encapsulated independently.  Finally, note that MIKEY already
  provides replay protection and that protection covers the General
  Extension Payload also.

[Ballot comment]
I support Cullen's Discuss and would recommend his
alternative #2 for the resolution. The IANA considerations
can perhaps say "Specification Required". See also RFC 4563
where 3GPP defined similar MIKEY extensions, but
decided to do them in an IETF RFC.

[Ballot discuss]
I see this document possible leading to considerably reduced interoperability. Basically it circumvents the IANA registry so that devices will end up receiving extensions yet have no way to find out what the extension is or what it means. It also will end up creating an OMA specific profile of MIKEY. I believe whatever code points the OMA BCAST S/LTKM requires should simply be registered as the current IANA registry instead of creating a container for them. This will result in smaller message, a clear registry where implementers can find a reference to where an extension is defined. Additionally, I worry that this document does not provide a way to make sure that there are not conflict better the many extension that will get stuck into it. If two other SDO's base there work on OMA's then it is not clear how both will allocate values inside of this general extension without having conflicts. This type of approach also leads to a profiling of MIKEY - if some other SDO, say PacketCable wanted pretty much the same functionality that this provided, there is no way for them to reuse or make extensions of this work since once again.

I can see a couple simple resolutions to this discuss. One, just register the things that would go inside this draft in the current IANA registry. Or as alternative two, proceed with this draft roughly as but require an IANA registry for all the things that can be put inside this Extension Payload and make sure that registry has appropriate registry mechanism for an protocol under IETF change control. That would also solve the circular reference problem as this document would only create the registry. I would make the extension not specific to OMA.

[Ballot discuss]
From SecDir Review by Sean Turner:

  In the security considerations the document says that if
  confidentiality is required it must be protected "in place".
  It is unclear what "in place" means.

[Ballot discuss]
Normative Reference [2] appears to be a work in progress in a proprietary format labelled Draft Version 1.0. It took some work to find it, so
here is the URL:

http://member.openmobilealliance.org/ftp/Public_documents/BAC/BCAST/Permanent_documents/OMA-TS-BCAST_SvcCntProtection-V1_0-20060412-D.zip

It carries an I-D like disclaimer:
"Unless this document is clearly designated as an approved specification, this document is a work in process, is not an approved Open Mobile Alliance specification, and is subject to revision or removal without notice."

Is this enough to support the requested registration?

IANA Last Call Comment:

Upon approval of this document, the IANA will make the following assignments
in the "Mikey Payload Name Spaces" registry located at
http://www.iana.org/assignments/mikey-payloads
in table General Extensions payload name spaces:
Type value Reference
OMA BCAST TBD [RFC-msec-mikey-genext-oma]

We understand the above to be the only IANA Actions for this document.