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

["Zhangdacheng (Dacheng)" <[e-mail]>]

Hi, Tiru:

Thanks again for the review. I've included most of the comments in the document. Please see my answers inline. 

Cheers

Dacheng

> -----Original Message-----
> From: pcp [mailto:[e-mail]] On Behalf Of Tirumaleswar Reddy
> (tireddy)
> Sent: Thursday, August 07, 2014 6:20 PM
> To: Dacheng Zhang; [e-mail]
> Subject: 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.
> 
[Dacheng Zhang:] 
Done!
> [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
[Dacheng Zhang:] 
Done!
> 
> [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
> Comment> not creating implicit mapping for specific traffic like UDP
> 
[Dacheng Zhang:] Update the document according to your comment, done!

> [4] This mechanism can be used to
>    secure PCP in the following situations::
> 
> Nit> Remove extra ":"
[Dacheng Zhang:] Done!
> 
> [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 ?
[Dacheng Zhang:] Please give me some time to think about it.
> 
> [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
> 
[Dacheng Zhang:] Done!
> [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.
[Dacheng Zhang:] Done!
> 
> [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"
[Dacheng Zhang:] Done!
> 
> [9] Do the Authentication tag option for PCP authentication message and
> authentication tag option for common PCP have different option codes ?
[Dacheng Zhang:] Yes, I think so. They contain different information.
> 
> [10] Update IANA Considerations with the new PCP option, opcode and result
> codes introduced in the draft.
[Dacheng Zhang:] 
Will do it before the next version.
> 
> [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.
[Dacheng Zhang:] 
Done!
> 
> [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.
> 
[Dacheng Zhang:] 
How about the following text?

" During a re-authentication procedure between a PCP server and a PCP proxy, the proxy SHOULD discard the mapping creation requests from its PCP clients if the PCP proxy does not already have a valid active mapping for this mapping-creation request. Because PCP clients are responsible for reliable delivery of PCP request messages, it will resend the requests. Then, after the re-authentication finishes, the requests will be processed. " 

> Cheers,
> -Tiru
> 
> > -----Original Message-----
> > From: Dacheng Zhang [mailto:[e-mail]]
> > Sent: Monday, July 21, 2014 8:35 PM
> > To: [e-mail]
> > 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/pcp
> > >
> >
> 
> _______________________________________________
> pcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pcp