Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers
draft-ietf-dime-ikev2-psk-diameter-11

[Ballot discuss]
After needed prodding, I've had a look at -10 of this wrt my
remaining discusses and I'm now able to break my remaining
issues down into what I hope are specific actionable and
mostly minor changes.

1)  top of p4 says:
  "In this use
  case Internet Key Exchange v2 (IKEv2) with pre-shared key based
  initiator authentication is used for the setup of the IPsec SAs."

But you need the peer and IKEv2 Server to not use standard
IPsec PSK but the different form of PSK defined here, so that's
misleading. I think you need to say something like:

  "In this use
  case Internet Key Exchange v2 (IKEv2) with a variant (for which
  a default is defined here) of pre-shared key based
  initiator authentication is used for the setup of the IPsec SAs. "

2) on p4 you say:

  "It is left to
  protocols leveraging this Diameter application to specify PSK
  derivation."

But that's no longer the case since you do define the "default"
way to do it. I'd say either delete the sentence or change it
to:

  "Other
  protocols leveraging this Diameter application MAY specify
  their own PSK derivation scheme."

3) in 4.1 you say:

  "If there is no PSK found associated with this IKEv2 Peer, the
  IKEv2 Server MUST send an Authorize-Only (Auth-Request-Type set to
  "Authorize-Only") Diameter IKEv2-PSK-Request message to the HAAA to
  obtain the PSK."

I don't get that and the previous sentence. Here you're talking
about "the PSK" as something the IKE v2 peer gets to see. But
in the default scheme (and in any sensible scheme probably) the
IKE v2 peer won't get to see the "*pre-shared* key but only a
derived key which is not *pre*-shared. I think you need to fix
this terminology and fix it throughout. The same happens later,
e.g. the term "PSK generation procedure" makes no sense really.
Nor does a formula like "PSK = KDF(...)". The last para of the
security considerations talks about "long lived PSK" which is
the usual meaning of the term but conflicts with all of the
uses above.

I think you need to fix this and to use consistent terms and
terms that actually make sense. How about changing to the use
of just "SK"/shared-key when the value is derived and keep
PSK/pre-shared key for cases where we're really dealing with
long term pre-shared keys? (You'd not need the "root key"
term then.)

This one maps to multiple edits, but each are easy - if the
value is derived, then use term#1 (my suggestion being "SK")
if the value is pre-existing/shared then use term#2 ("PSK").
If you prefer other terms that's fine so long as those are
a) not confusing and b) used consistently.

5) In 4.1 where you specify the KDF input, what is "length"
the length of? In 5295 it specifies the key length that you
want output from the KDF. I've no idea if that's what you
mean here but if you do want that you need to say it.

[Ballot comment]
"It is expected..." in the security considerations is no longer
correct. If you're using the Key AVP then draft-ietf-dime-keytran
(which is now at -14 btw) then that says that you MUST only
send via TLS or IPsec if the Key AVP isn't self-protecting
which applies here, at least for the default. I think this fact
means that some of the other text in these security
considerations is no longer needed.

There's no change required here really but I wanted to
point it out since its a post-WG change to keytran that was
made since I first reviewed this document.

[Ballot discuss]
After needed prodding, I've had a look at -10 of this wrt my
remaining discusses and I'm now able to break my remaining
issues down into what I hope are specific actionable and
mostly minor changes.

1)  top of p4 says:
  "In this use
  case Internet Key Exchange v2 (IKEv2) with pre-shared key based
  initiator authentication is used for the setup of the IPsec SAs."

But you need the peer and IKEv2 Server to not use standard
IPsec PSK but the different form of PSK defined here, so that's
misleading. I think you need to say something like:

  "In this use
  case Internet Key Exchange v2 (IKEv2) with a variant (for which
  a default is defined here) of pre-shared key based
  initiator authentication is used for the setup of the IPsec SAs. "

2) on p4 you say:

  "It is left to
  protocols leveraging this Diameter application to specify PSK
  derivation."

But that's no longer the case since you do define the "default"
way to do it. I'd say either delete the sentence or change it
to:

  "Other
  protocols leveraging this Diameter application MAY specify
  their own PSK derivation scheme."

3) in 4.1 you say:

  "If there is no PSK found associated with this IKEv2 Peer, the
  IKEv2 Server MUST send an Authorize-Only (Auth-Request-Type set to
  "Authorize-Only") Diameter IKEv2-PSK-Request message to the HAAA to
  obtain the PSK."

I don't get that and the previous sentence. Here you're talking
about "the PSK" as something the IKE v2 peer gets to see. But
in the default scheme (and in any sensible scheme probably) the
IKE v2 peer won't get to see the "*pre-shared* key but only a
derived key which is not *pre*-shared. I think you need to fix
this terminology and fix it throughout. The same happens later,
e.g. the term "PSK generation procedure" makes no sense really.
Nor does a formula like "PSK = KDF(...)". The last para of the
security considerations talks about "long lived PSK" which is
the usual meaning of the term but conflicts with all of the
uses above.

I think you need to fix this and to use consistent terms and
terms that actually make sense. How about changing to the use
of just "SK"/shared-key when the value is derived and keep
PSK/pre-shared key for cases where we're really dealing with
long term pre-shared keys? (You'd not need the "root key"
term then.)

This one maps to multiple edits, but each are easy - if the
value is derived, then use term#1 (my suggestion being "SK")
if the value is pre-existing/shared then use term#2 ("PSK").
If you prefer other terms that's fine so long as those are
a) not confusing and b) used consistently.

5) In 4.1 where you specify the KDF input, what is "length"
the length of? In 5295 it specifies the key length that you
want output from the KDF. I've no idea if that's what you
mean here but if you do want that you need to say it.

[Ballot discuss]
The Gen-ART Review by Ben Campbell on 3-Jun-2011 raised an important
  interoperability question.  Ben pointed out that the the procedure
  used by the HAAA to generate the PSK is out of scope, but that
  interoperability cannot occur unless the same one is supported by all
  parties.  The author responded that the PSK generation is important
  for interoperability, but that the specific PSK generation mechanisms
  have been intentionally left to other documents.  Thus, the Diameter
  application must define the PSK generation mechanism.  Apparently,
  3GPP2 has such documents for its community.

  I would like to understand why the IETF is not specifying a mandatory
  to implement PSK generation mechanism, even if others are allowed.
  This could be done with a normative reference.

[Ballot discuss]
--- two more parts of this were obviously cleared (what were discuss
points 1 & 8); I'll look at the others in a bit but no harm getting these
out of the way

(1) cleared

(2) This specification calls for sending a symmetric key
(realistically , in clear) in Diameter and then using that key to
secure an IPsec SA establishment.  The set of conditions under
which that is a reasonable thing to do (which may be the empty set)
need to be identified, but are not.  For example, if the Diameter
and IKE exchanges share a network segment then this is fairly
pointless if there is a MITM.

(3) (Similar to, but not identical to (2).) Routing the request
based on IDi (as an NAI) seems to make it very hard to do that with
security, unless there is some way to validate the domain component
of the NAI (e.g via a whitelist or some broker). How is this done?
If any old IDi/NAI value can be used, then it seems impossible to
always setup a secure channel for the return of the key, which
implies that the key effectively MUST be returned in clear, which
seems unacceptable.

(4) cleared

(5) What does this mean: "It is strongly RECOMMENDED that the HAAA
uses the nonces Ni and Nr received in IKEv2-Nonces AVP to generate
the PSK. " Are you changing IKE here? An IKE PSK is not "generated"
it just is. (Apologies if I'm missing something here, but IKE's
use of EAP is not something with which I'm very familiar.)

(6) cleared

(7) How does a programmer handle this statement in the draft: "For
this reason, this specification strongly recommends using Diameter
agents that can be trusted."? I think you have to have a MUST
implement and MUST use TLS and that brokers MUST NOT be used if you
want the Key AVP to be protected from the HAAA to the requesting
node. Anything else needs to be specifically justified.

(8) cleared

[Ballot discuss]
This is an updated discuss based on the -09 version:

- cleared

- cleared

- I support Stephen's discuss positions.  (FYI - this is so I can follow along with the discussion).

[Ballot discuss]
--- two more parts of this were obviously cleared (what were discuss
points 1 & 8); I'll look at the others in a bit but no harm getting these
out of the way

(1) cleared

(2) This specification calls for sending a symmetric key
(realistically , in clear) in Diameter and then using that key to
secure an IPsec SA establishment.  The set of conditions under
which that is a reasonable thing to do (which may be the empty set)
need to be identified, but are not.  For example, if the Diameter
and IKE exchanges share a network segment then this is fairly
pointless if there is a MITM.

(3) (Similar to, but not identical to (2).) Routing the request
based on IDi (as an NAI) seems to make it very hard to do that with
security, unless there is some way to validate the domain component
of the NAI (e.g via a whitelist or some broker). How is this done?
If any old IDi/NAI value can be used, then it seems impossible to
always setup a secure channel for the return of the key, which
implies that the key effectively MUST be returned in clear, which
seems unacceptable.

(4) Sending IDi, Ni and Nr out-of-band of the IKEv2 exchange might
lead to new attacks. For example, if I can feed selected Ni,Nr to
someone who does crypto on those and gives me the result, then I
may get to figure out a secret more easily than planned. Normally
in IKE, IDi is only sent encrypted, but that differs here. Has this
been analysed? (And where are the results?) If not, it should be.

(5) What does this mean: "It is strongly RECOMMENDED that the HAAA
uses the nonces Ni and Nr received in IKEv2-Nonces AVP to generate
the PSK. " Are you changing IKE here? An IKE PSK is not "generated"
it just is. (Apologies if I'm missing something here, but IKE's
use of EAP is not something with which I'm very familiar.)

(6) cleared

(7) How does a programmer handle this statement in the draft: "For
this reason, this specification strongly recommends using Diameter
agents that can be trusted."? I think you have to have a MUST
implement and MUST use TLS and that brokers MUST NOT be used if you
want the Key AVP to be protected from the HAAA to the requesting
node. Anything else needs to be specifically justified.

(8) cleared

[Ballot discuss]
(1) The writing here is unclear at critical points, to the point
where I find this hard to follow. I would recommend expanding and
clarifying the 2nd paragraph of the introduction; e.g. adding a
diagram showing the various parties involved in the exchanges;
introducing the main use-case for this protocol and defining terms
before use - in particular the IKEv2 Server and Peer, HAAA etc. The
purpose of the IPsec exchange also needs to be explained.  Without
this its not really possible (for me anyway) to know if the main
potential problem with this spec (sending cleartext keys) is fatal
or not.

(2) This specification calls for sending a symmetric key
(realistically , in clear) in Diameter and then using that key to
secure an IPsec SA establishment.  The set of conditions under
which that is a reasonable thing to do (which may be the empty set)
need to be identified, but are not.  For example, if the Diameter
and IKE exchanges share a network segment then this is fairly
pointless if there is a MITM.

(3) (Similar to, but not identical to (2).) Routing the request
based on IDi (as an NAI) seems to make it very hard to do that with
security, unless there is some way to validate the domain component
of the NAI (e.g via a whitelist or some broker). How is this done?
If any old IDi/NAI value can be used, then it seems impossible to
always setup a secure channel for the return of the key, which
implies that the key effectively MUST be returned in clear, which
seems unacceptable.

(4) Sending IDi, Ni and Nr out-of-band of the IKEv2 exchange might
lead to new attacks. For example, if I can feed selected Ni,Nr to
someone who does crypto on those and gives me the result, then I
may get to figure out a secret more easily than planned. Normally
in IKE, IDi is only sent encrypted, but that differs here. Has this
been analysed? (And where are the results?) If not, it should be.

(5) What does this mean: "It is strongly RECOMMENDED that the HAAA
uses the nonces Ni and Nr received in IKEv2-Nonces AVP to generate
the PSK. " Are you changing IKE here? An IKE PSK is not "generated"
it just is. (Apologies if I'm missing something here, but IKE's
use of EAP is not something with which I'm very familiar.)

(6) cleared

(7) How does a programmer handle this statement in the draft: "For
this reason, this specification strongly recommends using Diameter
agents that can be trusted."? I think you have to have a MUST
implement and MUST use TLS and that brokers MUST NOT be used if you
want the Key AVP to be protected from the HAAA to the requesting
node. Anything else needs to be specifically justified.

(8) IKE_AUTH has an optional IDr field. That doesn't seem to be
mentioned here at all. I'd have thought that it ought be in the
IKEv2-PSK-Request if it was in the IKE_AUTH message? (I need to
check if IDr can occur with an IKEv2 PSK, but seems like it ought
be allowed.)

[Ballot discuss]
- Is there any reason this draft can't point to 3588bis?  It's at version -26.  Isn't it close to being done?  In that draft, they make IPsec the secondary mechanism and TLS/DTLS the primary a switch from 3588.

- Yaron pointed out that packing additional semantics in to the SPI may conflict with other elements in the IPsec architecture (e.g., failure-detection).  Shouldn't this be pointed out in the draft?

- I support Stephen's discuss positions.  (FYI - this is so I can follow along with the discussion).

[Ballot comment]
Regarding other Discusses, I am actually fine with the document otherwise except the above point, and with some documentation of the security assumptions and implications it should be possible to publish it.

However, I do have one additional concern that should be discussed. I'm not too happy about the decision to leave the PSK generation algorithm outside the scope of this specification. It basically means that there is no interoperability.

[Ballot discuss]
The document says:

> 6.1.1. Ni
>
>  The Ni AVP (AVP Code TBD5) is of type Unsigned32 and contains the
>  IKEv2 initiator nonce.
>
> 6.1.2. Nr
>
>  The Nr AVP (AVP Code TBD6) is of type Unsigned32 and contains the
>  IKEv2 responder nonce.

However, Section 3.9 of RFC 4306 clearly states that nonces are variable length. How can you carry a variable length nonce in an Unsigned32?

[Ballot comment]
I support Russ' discuss.

I also encourage stating more clearly that there is no mechanism for negotiating/detecting which PSK derivation algorithm is in use - that this is entirely manually managed configuration. Is it realistic that this would be run-time configuration, or is it expected that it would be set at manufacture or compile?

[Ballot discuss]
The Gen-ART Review by Ben Campbell on 3-Jun-2011 raised an important
  interoperability question.  Ben pointed out that the the procedure
  used by the HAAA to generate the PSK is out of scope, but that
  interoperability cannot occur unless the same one is supported by all
  parties.  The author responded that the PSK generation is important
  for interoperability, but that the specific PSK generation mechanisms
  have been intentionally left to other documents.  Thus, the Diameter
  application must define the PSK generation mechanism.  Apparently,
  3GPP2 has such documents for its community.

  I would like to understand why the IETF is not specifying a mandatory
  to implement PSK generation mechanism, even if others are allowed.
  This could be done with a normative reference.

[Ballot discuss]
(1) The writing here is unclear at critical points, to the point
where I find this hard to follow. I would recommend expanding and
clarifying the 2nd paragraph of the introduction; e.g. adding a
diagram showing the various parties involved in the exchanges;
introducing the main use-case for this protocol and defining terms
before use - in particular the IKEv2 Server and Peer, HAAA etc. The
purpose of the IPsec exchange also needs to be explained.  Without
this its not really possible (for me anyway) to know if the main
potential problem with this spec (sending cleartext keys) is fatal
or not.

(2) This specification calls for sending a symmetric key
(realistically , in clear) in Diameter and then using that key to
secure an IPsec SA establishment.  The set of conditions under
which that is a reasonable thing to do (which may be the empty set)
need to be identified, but are not.  For example, if the Diameter
and IKE exchanges share a network segment then this is fairly
pointless if there is a MITM.

(3) (Similar to, but not identical to (2).) Routing the request
based on IDi (as an NAI) seems to make it very hard to do that with
security, unless there is some way to validate the domain component
of the NAI (e.g via a whitelist or some broker). How is this done?
If any old IDi/NAI value can be used, then it seems impossible to
always setup a secure channel for the return of the key, which
implies that the key effectively MUST be returned in clear, which
seems unacceptable.

(4) Sending IDi, Ni and Nr out-of-band of the IKEv2 exchange might
lead to new attacks. For example, if I can feed selected Ni,Nr to
someone who does crypto on those and gives me the result, then I
may get to figure out a secret more easily than planned. Normally
in IKE, IDi is only sent encrypted, but that differs here. Has this
been analysed? (And where are the results?) If not, it should be.

(5) What does this mean: "It is strongly RECOMMENDED that the HAAA
uses the nonces Ni and Nr received in IKEv2-Nonces AVP to generate
the PSK. " Are you changing IKE here? An IKE PSK is not "generated"
it just is. (Apologies if I'm missing something here, but IKE's
use of EAP is not something with which I'm very familiar.)

(6) RFC 3588, section 4.5 has an "Encr" colum that is missing in
the AVP flag rules here and that is presumably very very important
for an AVP named Key.  What's up there? Would adding the Encr
column with a "Y" for the key be the right thing?

(7) How does a programmer handle this statement in the draft: "For
this reason, this specification strongly recommends using Diameter
agents that can be trusted."? I think you have to have a MUST
implement and MUST use TLS and that brokers MUST NOT be used if you
want the Key AVP to be protected from the HAAA to the requesting
node. Anything else needs to be specifically justified.

(8) IKE_AUTH has an optional IDr field. That doesn't seem to be
mentioned here at all. I'd have thought that it ought be in the
IKEv2-PSK-Request if it was in the IKE_AUTH message? (I need to
check if IDr can occur with an IKEv2 PSK, but seems like it ought
be allowed.)

[Ballot comment]
I am neither an IKE person nor a Diameter person. That said, the following sentence, which appears in the Abstract and Introduction, is completely incomprehensible to me:

  This document specifies IKEv2 server, as a Diameter
  client, to the Diameter server communication for IKEv2 with pre-
  shared key based authentication.

If IKE and Diameter people will understand that sentence, you can feel free to ignore me, but I have no idea what that means.

Upon approval of this document, IANA understands that there are three
IANA Actions which must be completed.

First, in the Command Codes subregistry of the Authentication,
Authorization, and Accounting (AAA) Parameters registry located at:

http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml#command-code-rules

a new registration is to be made as follows:

Code Value: < TBD >
Name: IKEv2-PSK-Request/Answer
Reference: [ RFC-to-be ]

Second, in the AVP Codes subregistry of the Authentication,
Authorization, and Accounting (AAA) Parameters registry located at:

http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml#command-code-rules

three new registrations are to be made as follows:

AVP Code: < TBD >
Attribute: IKEv2-Nonces
Reference: [ RFC-to-be ]

AVP Code: < TBD >
Attribute: Ni
Reference: [ RFC-to-be ]

AVP Code: < TBD >
Attribute: Nr
Reference: [ RFC-to-be ]

Third, in the Application IDs subregistry of the Authentication,
Authorization, and Accounting (AAA) Parameters registry located at:

http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml#command-code-rules

a new registration is to be made as follows:

ID value: < TBD >
Name: Diameter IKE PSK (IKEPSK)
Reference: [ RFC-to-be ]

IANA understands that these three actions are the only ones that need to
be completed upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server to Diameter Server Interaction) to Proposed Standard


The IESG has received a request from the Diameter Maintenance and
Extensions WG (dime) to consider the following document:
- 'Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server
  to Diameter Server Interaction'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-06-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The Internet Key Exchange protocol version 2 (IKEv2) is a component
  of the IPsec architecture and is used to perform mutual
  authentication as well as to establish and to maintain IPsec security
  associations (SAs) between the respective parties.  IKEv2 supports
  several different authentication mechanisms, such as the Extensible
  Authentication Protocol (EAP), certificates, and pre-shared secrets.

  With [RFC5778] the Diameter interworking for Mobile IPv6 between the
  Home Agent, as a Diameter client, and the Diameter server has been
  specified.  However, that specification focused on the usage of EAP
  and did not include support for pre-shared secret based
  authentication available with IKEv2.  This document specifies IKEv2
  server, as a Diameter client, to the Diameter server communication
  for IKEv2 with pre-shared secret based authentication.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dime-ikev2-psk-diameter/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dime-ikev2-psk-diameter/


No IPR declarations have been submitted directly on this I-D.

(1.a) Who is the Document Shepherd for this document? Has the

Document Shepherd personally reviewed this version of the

document and, in particular, does he or she believe this

version is ready for forwarding to the IESG for publication?



--

Lionel Morand (lionel.morand@orange-ftgroup.com)

is the Document Shepherd, Dime co-chair. He has done a review

on the document and believes it is ready to be forwarded to

IESG for publication.



(1.b) Has the document had adequate review both from key WG members

and from key non-WG members? Does the Document Shepherd have

any concerns about the depth or breadth of the reviews that

have been performed?



--

The document has had an extensive review by the DIME WG and

the lastest version is the result of the consensus reached

within the WG.



The shepherd has reviewed the document himself and has no

issue with it. Nor the shepherd has issues with the reviews

done by others.



(1.c) Does the Document Shepherd have concerns that the document

needs more review from a particular or broader perspective,

e.g., security, operational complexity, someone familiar with

AAA, internationalization or XML?



--

No.





(1.d) Does the Document Shepherd have any specific concerns or

issues with this document that the Responsible Area Director

and/or the IESG should be aware of? For example, perhaps he

or she is uncomfortable with certain parts of the document, or

has concerns whether there really is a need for it. In any

event, if the WG has discussed those issues and has indicated

that it still wishes to advance the document, detail those

concerns here. Has an IPR disclosure related to this document

been filed? If so, please include a reference to the

disclosure and summarize the WG discussion and conclusion on

this issue.



--

No.





(1.e) How solid is the WG consensus behind this document? Does it

represent the strong concurrence of a few individuals, with

others being silent, or does the WG as a whole understand and

agree with it?



--

There is Dime WG consensus behind the document.





(1.f) Has anyone threatened an appeal or otherwise indicated extreme

discontent? If so, please summarise the areas of conflict in

separate email messages to the Responsible Area Director. (It

should be in a separate email because this questionnaire is

entered into the ID Tracker.)



--

No.



(1.g) Has the Document Shepherd personally verified that the

document satisfies all ID nits? (See the Internet-Drafts
Checklist

and http://tools.ietf.org/tools/idnits/). Boilerplate checks are


not enough; this check needs to be thorough. Has the document

met all formal review criteria it needs to, such as the MIB

Doctor, media type and URI type reviews?



--

The shepherd has checked the document with the idnits tool.

There is only one issue: the reference to the IKEv2 protocol
needs to

be updated (from RFC 4306 to RFC 5996).

The document does not need MIB doctor review.

The document does not contain any media and URI types.



(1.h) Has the document split its references into normative and

informative? Are there normative references to documents that

are not ready for advancement or are otherwise in an unclear

state? If such normative references exist, what is the

strategy for their completion? Are there normative references

that are downward references, as described in [RFC3967]? If

so, list these downward references to support the Area

Director in the Last Call procedure for them [RFC3967].



--

References are split accordingly.

There is a normative reference to a draft
(draft-ietf-dime-local-keytran)

but a request for publication has been already sent for this
draft.

There are no other references to documents with unclear status
or

are in progress.



(1.i) Has the Document Shepherd verified that the document IANA

consideration section exists and is consistent with the body

of the document? If the document specifies protocol

extensions, are reservations requested in appropriate IANA

registries? Are the IANA registries clearly identified? If

the document creates a new registry, does it define the

proposed initial contents of the registry and an allocation

procedure for future registrations? Does it suggest a

reasonable name for the new registry? See [RFC5226]. If the

document describes an Expert Review process has Shepherd

conferred with the Responsible Area Director so that the IESG

can appoint the needed Expert during the IESG Evaluation?



--

This document defines a new Diameter application and 3 new AVP
codes.

IANA is requested to allocate values for the application id and
the AVP codes.

IANA is also requested to assign a new value for the Key-Type
AVP from the

registry defined by the draft draft-ietf-dime-local-keytran-08.
This registry

will have to be created first.



No new registry is defined..





(1.j) Has the Document Shepherd verified that sections of the

document that are written in a formal language, such as XML

code, BNF rules, MIB definitions, etc., validate correctly in

an automated checker?



--

Yes. Note that the ABNF used in this document follows the

modified ABNF syntax defined in RFC3588.





(1.k) The IESG approval announcement includes a Document

Announcement Write-Up. Please provide such a Document

Announcement Write-Up? Recent examples can be found in the

"Action" announcements for approved documents. The approval

announcement contains the following sections:



Technical Summary



--



This document therefore extends
the functionality offered by the Diameter Mobile IPv6 application
[RFC 5778] with pre-shared key based
authentication offered by IKEv2 when no EAP is used.






Working Group Summary



---

The document was discussed for more than one year in the WG and


the document captures the results of the collaborative WG work.



Document Quality



---

The document is complete, straightforward, simple and
well-written.