Re: [pcp] I-D Action: draft-ietf-pcp-authentication-04.txt

Hi Dacheng,

My comments:

[1] ID Indicator: The value for a PCP client to choose proper
      credentials for authentication.  The method of generating this
      value is out of scope of this document.  Note this field MUST end
      on a 32-bit boundary, padded with 0's when necessary.

Comment> ID indicator should be user-friendly. For example check out A-ID-Info in EAP-FAST.

[2] Each PA message is attached with an
   Authentication OpCode and may optionally contain a set of Options for
   various purposes (e.g., transporting authentication messages and
   session managements).

Nit> replace session managements with session management

[3]   o  On security infrastructure equipment, such as corporate firewalls,
      that does not create implicit mappings.

Comment> The above line is very clear, are you referring to firewalls not creating implicit mapping for specific traffic like UDP

[4] This mechanism can be used to
   secure PCP in the following situations::

Nit> Remove extra ":"

[5]
The draft says fragmentation and re-assembly is handled by EAP methods but http://tools.ietf.org/html/rfc3748 explains that it's only handled by EAP-TLS.  

Does that make EAP-TLS mandatory to support ?

[6] In this case, before sending
   out the PA-Server, the PCP server must update the SA and use the new
   key to generate digests to protect the integrity and authenticity of
   the PA-Server and any subsequent PCP message.

Nit> replace digests with digest

[7]  Because there is no authenticaiton OpCode in common PCP messages, the
   authentication tag for common PCP messages needs to provide the
   inforamtion of session ID and sequence numbers.

Nit> Fix spelling mistakes for authenticaiton, inforamtion.

[8] The generation of the digest can be various according to the algorithms specified in different PCP SAs.
Comment> Replace the above line with
"The generation of the digest varies according to the algorithm finalized in different PCP SAs"

[9] Do the Authentication tag option for PCP authentication message and authentication tag option for common PCP have different option codes ? 

[10] Update IANA Considerations with the new PCP option, opcode and result codes introduced in the draft.

[11]   This section applies only to the in-band key management mechanism.
 It will need to be updated if the WG choose to pursue the out-of-band
 key management mechanism discussed above.

Comment> I think the above paragraph can be removed.

[12] I think a section is required to explain how PCP authentication works in the presence of PCP proxies ?
        In specific explain what happens when PCP proxy and PCP server are involved in re-authentication while PCP clients are sending PCP requests.

Cheers,
-Tiru

> -----Original Message-----
> From: Dacheng Zhang [mailto:zhang_dacheng@hotmail.com]
> Sent: Monday, July 21, 2014 8:35 PM
> To: pcp@ietf.org
> Subject: [pcp] I-D Action: draft-ietf-pcp-authentication-04.txt
> 
> Hi, in this version of the document, we try to address the comments got since
> the last meeting.  Particularly, we:
>    o  Refine the retransmission policies.
> 
>    o  Provide the discussion about how to instruct a PCP client to
>       choose proper credential during authenticaiton, and an ID
>       Indication Option is defined for that purpose.
> In addition, it is advised that we should remove the key ID from the PCP
> authentication message, and only use one key for a PCP session. However,
> this indicates we will use the MSK to generate MACs for PCP message directly.
> We would like to check with the group again before including it into the
> document.
> 
> Any comments and suggestions are appreciated.
> 
> Cheers
> 
> Dacheng
> 
> 
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Port Control Protocol Working Group of the
> IETF.
> >
> >        Title           : Port Control Protocol (PCP) Authentication Mechanism
> >        Authors         : Margaret Wasserman
> >                          Sam Hartman
> >                          Dacheng Zhang
> > 	Filename        : draft-ietf-pcp-authentication-04.txt
> > 	Pages           : 24
> > 	Date            : 2014-07-21
> >
> > Abstract:
> >   An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to
> >   flexibly manage the IP address and port mapping information on
> >   Network Address Translators (NATs) or firewalls, to facilitate
> >   communications with remote hosts.  However, the un-controlled
> >   generation or deletion of IP address mappings on such network devices
> >   may cause security risks and should be avoided.  In some cases the
> >   client may need to prove that it is authorized to modify, create or
> >   delete PCP mappings.  This document proposes an in-band
> >   authentication mechanism for PCP that can be used in those cases.
> >   The Extensible Authentication Protocol (EAP) is used to perform
> >   authentication between PCP devices.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-pcp-authentication/
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-pcp-authentication-04
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-authentication-04
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > pcp mailing list
> > pcp@ietf.org
> > https://www.ietf.org/mailman/listinfo/pcp
> >
> 