IANA Registry Update for Support of the SEED Cipher Algorithm in Multimedia Internet KEYing (MIKEY)
draft-seokung-msec-mikey-seed-05

[Ballot comment]
I cleared.

My Discuss said...

> I note that the IANA registries that are added to have "undefined"
> registration procedures (presumably because section 4.2.9 of
> RFC 3830 is vague). But section 10 of RFC 3830 says that "Unless
> explicitly stated otherwise, values in the range 0-240 for each name
> space SHOULD be approved by the process of IETF consensus."
>
> Would someone take the action of helping IANA get the registries
> updated?

Brian Weis says...

| I guess as the current WG chair for the WG that published RFC 3830
| I am probably the "delegated responsible person (TM)" for getting
| it fixed. :-)  I'll do what I can, and check with my AD to see if
| he can issue you the assurance you're looking for

I'm hoping that this will get picked up and resolved.

[Ballot discuss]
Discuss

I note that the IANA registries that are added to have "undefined" registration procedures (presumably because section 4.2.9 of RFC 3830 is vague). But section 10 of RFC 3830 says that "Unless explicitly stated otherwise, values in the range 0-240 for each name space SHOULD be approved by the process of IETF consensus."

We had an IETF last call, so all is well.

Would someone take the action of helping IANA get the registries updated?

[Ballot comment]
I have a similar concern as the one expressed by Cullen, considering whether this document should not be marked as updating RFC 3830. It is difficult to understand how people reading that RFC would be aware that the one byte registries defined in 6.10.1.b and 6.10.1.d have more values assigned - they need to go and look into the IANA registries to figure out and this looks clumsy.

[Ballot discuss]
The way this is written it seems like it needs to update 3830. However, if it is going to update 3830, it brings up the question of if it needs to be PS or not. To be interoperable, it is unclear to me how this will be negotiated and what security advice should be provided about using say AES or SEED when both are available.

[Ballot discuss]
Discuss-Discuss (will clear on the call)

I note that the IANA registries that are added to have "undefined" registration procedures (presumably because section 4.2.9 of RFC 3830 is vague). But section 10 of RFC 3830 says that "Unless explicitly stated otherwise, values in the range 0-240 for each name space SHOULD be approved by the process of IETF consensus."

We had an IETF last call, so all is well.

Would someone take the action of helping IANA get the registries updated?

IANA questions/comments:

Upon approval of this document, IANA will make the following
assignments in the "Multimedia Internet KEYing (Mikey) Payload Name
Spaces" registry at
http://www.iana.org/assignments/mikey-payloads

ATTENTION: Please see the questions below about the assignment
requested in the SRTP Pseudo Random Function sub-registry.


===================
===================
Sub-registry: Encryption algorithm (Value 1)

OLD:

Value SRTP encr alg Reference
------- ------------------- ---------
0 NULL [RFC3830]
1 AES-CM [RFC3830]
2 AES-F8 [RFC3830]
3-240 Unassigned
241-255 Reserved

NEW:

Value SRTP encr alg Reference
------- ------------------- ---------
0 NULL [RFC3830]
1 AES-CM [RFC3830]
2 AES-F8 [RFC3830]
3 SEED-CTR [RFC-seokung-msec-mikey-seed-02]
4 SEED-CCM [RFC-seokung-msec-mikey-seed-02]
5 SEED-GCM [RFC-seokung-msec-mikey-seed-02]
6-240 Unassigned
241-255 Reserved


===================
===================
Sub-registry: SRTP Pseudo Random Function (Value 5)


OLD:

Value SRTP PRF Reference
------- ------------------- ---------
0 AES-CM [RFC3830]
1-240 Unassigned
241-255 Reserved

NEW:

Value SRTP PRF Reference
------- ------------------- ---------
0 AES-CM [RFC3830]
1 SEED-CTR [RFC-seokung-msec-mikey-seed-02]
2-240 Unassigned
241-255 Reserved


QUESTION: The current registry assigns 0 to AES-CM. The draft, however,
shows AES-CM with a value of 1 and requests the value of 2 for the new
assignment (SEED-CTR). We are guessing that the authors intended to
assign the next available value for the new requested assignment,
thereby assigning 1 to SEED-CTR. Is this correct?

Document Shepherd Write-Up

Title: Addition of the new values to use the SEED Cipher Algorithm in
the Multimedia Internet KEYing (MIKEY)

ID:  (-02
to be submitted by the authors ASAP)

Intended Status: Informational

Answers to Document Shepherd Write-Up questions (Questions listed in
the end):
1.a - Brian Weis is the document Shepherd.  He has personally reviewed
the document and asserts that it is ready for IESG publication.
1.b - The document has been reviewed by myself. The document merely
adds namespaces to an existing IANA MIKEY registry, and I do not deem
a further review necessary.
1.c - There is no need for wider review.
1.d - There are no specific concerns of which the AD and/or IESG
should be aware.
1.e - This is not a WG draft, therefore no WG consensus is necessary.
1.f - There has been no threat of appeal.
1.g - The document satisfies all ID nits with one false-positive
warning.
1.h - The document splits its references. All normative references are
complete and approved documents except for I-D.ietf-avt-seed-srtp,
which is a co-dependancy. That document is currently in IETF
evaluation, and all DISCUSSes have been resolved as of this writing.
It seems very likely that the AVT document will be approved prior to
this document.
1.i - The IANA Considerations section is consistent with the body of
the document. The document adds values to two existing registries.
1.j - No sections of the document are written in a formal language.

Technical Summary

This document proposes the addition of new values to use the SEED
block cipher algorithm for the Secure Real-time Transport Protocol
(SRTP) and the Real-time Transport Control Protocol (RTCP) in
Multimedia Internet KEYing (MIKEY). The document identified new
algorithm types in the MIKEY namespace.

Working Group Summary

This I-D was discussed in an MSEC WG meeting, and there were no
objections to the I-D progressing. However it was determined that
there was no need for the WG to progress it.

Document Quality

The editorial quality and technical quality of the document are both
in good shape.

State Change Notice email list have been change to seokung@kisa.or.kr, yjwon@kisa.or.kr, hcjung@kisa.or.kr, draft-seokung-msec-mikey-seed@tools.ietf.org, bwe@cisco.com from seokung@kisa.or.kr, yjwon@kisa.or.kr, hcjung@kisa.or.kr, draft-seokung-msec-mikey-seed@tools.ietf.org