Subject: [pcp] Fwd: Comments on draft-wasserman-pcp-authentication-02

From: Margaret Wasserman <[email-masked]>
Date: Mon, 2 Apr 2012 12:17:35 -0400

Just FYI --

We received these comments on draft-wasserman-pcp-authentication-02, and we will attempt to address these issues (where still pertinent) in the next version of the draft.

Margaret

Begin forwarded message:

> From: Josh Howlett <[email-masked]>
> Date: March 27, 2012 8:58:13 AM EDT
> To: Margaret Wasserman <[email-masked]>, Sam Hartman <[email-masked]>, "[email-masked]" <[email-masked]>
> Subject: Comments on draft-wasserman-pcp-authentication-02
> 
> Hi all,
> 
> I just reviewed draft-wasserman-pcp-authentication-02 very quickly; a few
> comments:
> 
> 0. A general point: I think it might be useful to cast the document more
> explicitly in term of a 'secure association protocol' (in the sense of
> RFC5247). It would probably make it easier to understand for the EAP
> community.
> 
> 1. The Message Type and Session ID fields seem to duplicate the functions
> of EAP's Type and Identifier fields.
> 
> 2. I think you need to specify MTI PRF(s) and MAC(s) for interoperability.
> The text does currently mandate the use of EAP methods that export MSK,
> but it is well hidden!
> 
> 3. EAP methods 'export' MSKs, not 'generate' them. Also RFC3748 does not
> define 'EAP key generating method[s]'; specific EAP methods do.
> 
> 4. I do not know much about PCP, but would it be interesting to return
> PCP-related policy using AAA attributes? Would it also be useful to
> discuss EAP pass-through? Presumably you would want to avoid configuring
> EAP credentials into routers?
> 
> 5. Could the EAP Reauthentication Protocol be useful here? Or is this not
> expected to be particularly dynamic?
> 
> 6. EAP methods are required to support fragmentation if their payloads are
> likely to exceed the EAP MTU. So I don't think the protocol needs
> fragmentation semantics.
> 
> 7. Specifically which offline attacks is the nonce protecting against?
> 
> 8. Why is the EAP Payload Option the only one that MUST be padded?
> 
> 9. I'm a bit confused hot where the options fit into the packet format.
> This is probably best discussed offline!
> 
> Josh.
> 
> 
> 
> Janet is a trading name of The JNT Association, a company limited
> by guarantee which is registered in England under No. 2881024 
> and whose Registered Office is at Lumen House, Library Avenue,
> Harwell Oxford, Didcot, Oxfordshire. OX11 0SG
>

---

From: "Zhangdacheng (Dacheng)" <[email-masked]>
Date: Mon, 9 Apr 2012 07:46:05 +0000

Hi, we are updating the draft according to Josh's comments. 

>>of EAP's Type and Identifier fields.
The message type filed is redundant while we expected to use the Session ID to detect antique messages in cooperate with sequence numbers. However, we later realize that the nonce exchanged between PCC and PCS can be used to achieve the same function. For example, assume both PCC and PCS select a random number as nonce at the beginning of the session to check each other's aliveness. The random numbers can be used to distinguish the messages within this session from the message in other sessions. Therefore, in the next version of the draft, we plan to remove the session ID and the Message Type fields, and plan to use nonce and sequence numbers to detect replay attacks. Comments? 

Cheers

Dacheng