Re: Please review docs on IESG Agenda for September 16, 2004

[Jari Arkko <jari.arkko@piuha.net>]

>   o draft-ietf-ipsec-ikev2-15.txt
>     Internet Key Exchange (IKEv2) Protocol (Proposed Standard) - 2 of 6 
>     Note: Back on agenda to see if the new version clears the remaining DISCUSS 
>     positions. 
>     Token: Russ Housley

I checked some of my old comments, to see if they were addressed.
Some were apparently missed. Here's the things that I would
like to see fixed:

The draft should refer to RFC 3748, not RFC 2284.

In Section 3.16, s/NAC/NAK/.

>    o  Type_Data (Variable Length) contains data depending on the Code
>       and Type. In Requests other than MD5-Challenge, this field
>       contains a prompt to be displayed to a human user. For NAK, it
>       contains one octet suggesting the type of authentication the
>       Initiator would prefer to use. For most other responses, it
>       contains the authentication code typed by the human user.

This is wrong. RFC 3748 clarified and extended what NAK contents
are. I would just suggest saying this:

"Type-Data

      The Type-Data field varies with the Type of Request and the
      associated Response. For the documentation of the
      EAP methods, see [RFC 3748]."

These points were originally made in:
http://www.vpnc.org/ietf-ipsec/mail-archive/msg00474.html

Then, I would suggest adding the following text to Appendix
A:

"(NN) To support authentication through the Extensible
Authentication Protocol (EAP) [ref]."

Also, change everywhere s/Extended Authentication Protocol/
Extensible Authentication Protocol/

This was recently discussed on the IPsec list:
(no list pointer available yet)

Finally, perhaps the below statement could be clarified:

>    Note that since IKE passes an indication of initiator identity in
>    message 3 of the protocol, EAP based prompts for Identity SHOULD NOT
>    be used.

This is somewhat problematic, because I'm not sure what
this means for an implementation, particularly for the client
side. I would suggest:

     Note that since IKE passes an indication of initiator identity
     in message 3 of the protocol, the responder SHOULD NOT send
     EAP Identity Requests. The initiator SHOULD, however, respond
     to such requests if it receives them.

The rationale for this is that it may be that a particular AAA
server insists on sending an identity request, and I wouldn't
like to see clients break because of this. See:
  http://mail.frascone.com/pipermail/eap/2004-September/002807.html
Also, there's some functinality in EAP that uses identity requests
so they may be necessary in some cases. See:
  http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-03.txt

--Jari