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

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 7 Aug 2014 10:19:48 +0000

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:[email-masked]]
> Sent: Monday, July 21, 2014 8:35 PM
> To: [email-masked]
> 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/pcp
> >
>

---

From: Dacheng Zhang <[email-masked]>
Date: Thu, 7 Aug 2014 20:36:47 +0800

Hi， Tiru：

Thanks a lot for the comments. I will integrate them into the document immediately. 

Cheers

Dacheng

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Fri, 8 Aug 2014 09:27:56 +0000

Hi, Tiru:

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

Cheers

Dacheng

> From: pcp [mailto:[email-masked]] On Behalf Of Tirumaleswar Reddy
> (tireddy)
> Sent: Thursday, August 07, 2014 6:20 PM
> To: Dacheng Zhang; [email-masked]
> Subject: Re: [pcp] I-D Action: draft-ietf-pcp-authentication-04.txt
> 
> Hi Dacheng,
> 
> My comments:
> 
[Dacheng Zhang:] 
Done!
> Nit> replace session managements with session management
[Dacheng Zhang:] 
Done!
> 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!

>    secure PCP in the following situations::
[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.
> 
[Dacheng Zhang:] Please give me some time to think about it.
> Nit> replace digests with digest
[Dacheng Zhang:] Done!
> Nit> Fix spelling mistakes for authenticaiton, inforamtion.
[Dacheng Zhang:] Done!
> "The generation of the digest varies according to the algorithm finalized in
[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.
> codes introduced in the draft.
[Dacheng Zhang:] 
Will do it before the next version.
>  It will need to be updated if the WG choose to pursue the out-of-band  key
> management mechanism discussed above.
> 
[Dacheng Zhang:] 
Done!
>         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. " 

> > Hi, in this version of the document, we try to address the comments
> > got since the last meeting.  Particularly, we:
> > 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.
> >

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 8 Aug 2014 11:17:00 +0000

Hi Dacheng,

Responding to the only ones which needs further discussion.

> >         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:]
> " During a re-authentication procedure between a PCP server and a PCP
> proxy, the proxy SHOULD discard the mapping creation requests from its PCP

It could be any PCP request (not just specific to mapping creation request)

> 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. "

The other variation is that in case of re-authentication b/w PCP proxy and PCP server, PCP proxy can use current SA to proxy the PCP request from the client and does not have to discard 
PCP messages. 

-Tiru

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Mon, 11 Aug 2014 06:25:43 +0000

> From: Tirumaleswar Reddy (tireddy) [mailto:[email-masked]]
> Sent: Friday, August 08, 2014 7:17 PM
> To: Zhangdacheng (Dacheng); [email-masked]
> Subject: RE: [pcp] I-D Action: draft-ietf-pcp-authentication-04.txt
> 
> Hi Dacheng,
> 
> > >         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:]
> > 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. "
> 
> The other variation is that in case of re-authentication b/w PCP proxy and PCP
> server, PCP proxy can use current SA to proxy the PCP request from the client
> and does not have to discard PCP messages.
[Dacheng Zhang:] 
I think it works. Before the current key are discarded by the new keys generated during the re-auth, this key can be used to protect the PCP-auth messages. So, it is also reasonable to used this key to protect the common pcp messages. Thanks for pointing this out. 

Cheers

Dacheng 
> > > > Hi, in this version of the document, we try to address the
> > > > comments got since the last meeting.  Particularly, we:
> > > > 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.
> > > > We would like to check with the group again before including it
> > > > into the document.
> > > >
> > > > > 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.
> > > > >

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Tue, 12 Aug 2014 08:01:58 +0000

Hi, I check the ticket list again.

#60: this ticket is about loosely coupled vs tightly coupled authentication. The discussion concluded that a solution can support both loosely coupled/tightly coupled authentication. So, we don't have to deal with ticket any more. 

I think the current solution have included all the comments in the 4 tickets. If there are any comments, please let me know. 

Cheers

Dacheng

> From: pcp [mailto:[email-masked]] On Behalf Of Dacheng Zhang
> Sent: Tuesday, July 22, 2014 2:35 AM
> To: Dave Thaler
> Cc: [email-masked]
> Hi, Dave:
> We didn't see any discussion about #60 and #62 in draft-reddy-pcp-auth-req-04.
> It seems the group didn't reach conclusions on those two issues.  Follows are
> the current status of the tickets.
> 
> #60: In the design we do not explicitly define the relationship between the life
> period of mappings and PCP-Auth sessions. However, it is assumed that the life
> period of a mapping could be longer than the period of the session where the
> mapping information is generated.
> 
> #61:  Unsolicited re-authenticaiton is defined in Section 3.3 since it is listed in
> draft-reddy-pcp-auth-req-04
> 
> #62: In the current design, re-transmission could be driven by either the client
> or the server. The PCP-auth protocol rather than EAP is responsible for
> retransmission.
> 
> ＃72：An new Option is defined in Section 6.11 to transport the information
> helping client to choose proper credentials during authentication.  That option
> MAY be transported in the initial PA-Sever message. But the way of specifying
> such information is out of scope of this paper.
> 
> Cheers
> 
> Dacheng
> 
> 
> 在 2014-7-21，上午11:09， Dave Thaler 写道：
> 
> > Thanks Dacheng for the update!
> >
> > There are currently 4 open tickets (see
> >
> http://trac.tools.ietf.org/wg/pcp/trac/query?status=new&status=assigned&st
> atus=reopened&component=authentication).
> > What do you believe the current status of each is, based on this update?
> >
> > -Dave
> >
> >> From: pcp [mailto:[email-masked]] On Behalf Of Dacheng Zhang
> >> Sent: Monday, July 21, 2014 11:05 AM
> >> To: [email-masked]
> >>> 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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 16 Aug 2014 07:43:15 +0000

> From: Zhangdacheng (Dacheng) [mailto:[email-masked]]
> Sent: Monday, August 11, 2014 11:56 AM
> To: Tirumaleswar Reddy (tireddy); [email-masked]
> > > > [12] I think a section is required to explain how PCP
> > > > authentication works in the presence of PCP proxies ?
> > > " 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. "
> >
> > The other variation is that in case of re-authentication b/w PCP proxy
> > and PCP server, PCP proxy can use current SA to proxy the PCP request
> > from the client and does not have to discard PCP messages.
> [Dacheng Zhang:]
> I think it works. Before the current key are discarded by the new keys
> generated during the re-auth, this key can be used to protect the PCP-auth
> messages. So, it is also reasonable to used this key to protect the common
> pcp messages. Thanks for pointing this out.

One corner case I forgot to comment earlier: When 32-bit sequence number reaches max value, authentication should be triggered to reset the value (similar to IPSEC where old SA is deleted and new one is established to reset sequence number).

-Tiru

> > > devices
> > > > > > http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-authentication
> > > > > > -0
> > > > > > 4
> > > > > >
> > > > > >
> > > > > > of submission until the htmlized version and diff are
> > > > > > available at
> > > tools.ietf.org.
> > > > > >