[Pana] Sam's IESG comments

["Alper Yegin" <alper.yegin at yegin.org>]

Hi Sam,

Thank you for the review and comments. Please see below for proposed
resolutions and let us know what you think.

Discuss [2007-06-21]:
First, I'd like to compliment Mark and the PANA working group on the
excellent work they have done over the last year.  I fully expected to
be unable to support publication of PANA when it came to the IESG.
While I do have some blocking comments, I think they are easy to
resolve and expect to be able to remove my discuss when that happens.
What an excellent job making PANA easier to understand and removing
complexity.

-> Thank you.

What must a receiver do if it receives a PANA message with unknown
version?  How is the version field actually useful?  (How do you get
backward compatibility if you discard packets with unknown version?)

-> I think version number must be updated only when we are about to
introduce an incompatible change. So I think (not sure though), if an
implementation receives a message with an unknown version number, it shall
silently ignore the message. I think a peer with version N+M cannot really
speak to another peer with version N unless the former implementation can
also behave like version N.

-> Does this make sense?



The framework document says that sometimes a PAC is expected to
reconfigure its address after PANA.  The PANA protocol has no
normative discussion of this.  In order to get interoperable
implementations, you need to clearly indicate when address
configuration is required.  Perhaps you are deferring this to future
documents.  If so, then the framework should indicate that unless a
PAC implements a protocol extension that mandates address
reconfiguration and that protocol extension is used, then the PAC need
not do address configuration.  Or, if address reconfig is supported in
the base protocol, you need to have normative language describing it.

-> We had thought about it and even designed an AVP to tell PaC what
mechanism to use for re-configuration. Version 12 of the spec included not
only an indication that the PaC shall reconfigure a new IP address but also
the name of the mechanism to use (DHCPv4, DHCPv6, stateless addr. autconf,
IKEv2, etc.).

-> Then we realized we were stepping outside the scope of the access
authentication, and we decided to remove it. We decided that anything with
IP address configuration is outside the scope. 

-> Would you suggest we re-introduce what we had but only with a one-bit
info that says "PaC shall configure a new IP address" (without enumerating
any specific address config mechanisms)?


The framework document talked about a lot of options having to do with
the underlying link and security.  It seems that the mandatory to
implement behavior from the protocol document is support for integrity
of PANA messages using EAP methods that produce MSKs but no mandatory
to implement support for link security either at layer 2 or 3.  If so,
please make this clear in the framework document.  If not, explain
what I'm missing.

-> That's right. 

-> In the introduction section, we had said:

   PANA is intended to be used in any access network regardless of the
   underlying security.  For example, the network might be physically
   secured, or secured by means of cryptographic mechanisms after the
   successful client-network authentication.

-> How about if we extend it to say:

   PANA is intended to be used in any access network regardless of the
   underlying security.  For example, the network might be physically
   secured, or secured by means of cryptographic mechanisms after the
   successful client-network authentication. While mandatory to
   implement behavior for a PANA deployment is the integrity
   of PANA messages when the EAP method produces MSK, there is no 
   mandatory to implement support for network security either at 
   the link-layer or network-layer.  

   



Section 5.5 of the protocol document should include a rule that
messages expected to have an auth attribute but which do not do so
MUST be discarded.  You need to specify which messages are expected to
have auth attributes (presumably all of them after a completed
authentication with an EAP method that generates an MSK).

-> We shall change 

   o  When an AUTH AVP is included, the AVP value matches the hash value
      computed against the received message.

-> To


   O  Once the PANA authentication succeeds using a key-generating EAP
      method, the PANA-Auth-Request message that carries the EAP Success
      and any subsequent message in that session contain an AUTH AVP. 
      The AVP value matches the hash value computed against the received 
      message.


Please describe how PANA will migrate to a new hash.  You need a
negotiation mechanism so that one side can determine the capabilities
of the other and so that you can maintain backward compatibility when
deploynig a new hash or PRF.

-> I'll leave that to Yoshi as he's the one who introduced the algorithm AVP
inspired from IKEv2. But in general let me ask: Does that mean we shall let
PAA send "a list of algorithms" and PaC choose one during the very first
PANA message exchange?


I am not sure the algorithm AVP quite gives you this.
Also, you SHOULD protect your negotiation after the fact so that  if an
attacker
modifies the unprotected negotiation then the modification will be detected.

-> We already include the negotiated algorithm in the very first
authenticated PANA message exchange (the one that carries the EAP success
from the PAA to the PaC, and its response). 

I'm particularly concerned that even if the  algorithm AVP is sufficient,
you
recommend against using it unless the link is secured.  That seems highly
problematic; protected negotiation is a better solution.

-> We allow inclusion of the Algorithm AVP in the very first message, so
that in case of a mismatch the PaC can decide not to continue. But in case
the link is not secured, that "early negotiation" is susceptible to
spoofing. So we wanted to warn the deployments. Would you recommend we
remove that warning? And would that not have an impact on the PaCs being
turned down due to a spoofed message?

I am uncomfortable with the claim in the protocol document's security
consideration section that physical security provides protection of
confidentiality and spoofing.  I'm not really sure that is true in any
reasonable sense for DSL lines.  I think a better way to state this is
that the environment provides adequate protection against spoofing and
confidentiality based on the operational needs of the environment.

Similarly, I'm concerned that the blanket claim that if a link does
not provide security then security is required at a higher layer.  I
agree that PANA integrity protection is required, but for example I
don't see why data origin authentication or connectionless integrity
is required for most Internet traffic.  I think the security
considerations section could be reworked to talk a lot more about
tradeoffs and a lot less about hard requirements.
Some hard requirements are probably still necessary.

-> We can remove references to any specific network types (DSL/3GPP2), and
physical vs. cryptographic security.

-> I think what we are really concerned is data origin authentication,
integrity and replay protection (not confidentiality, like the current spec
is saying). Those are important, because they are the primary tools for
enforcement points in policing the data traffic. Unless there is a way to
perform data origin authentication, the enforcement points cannot
distinguish traffic of authenticated clients from unauthenticated clients.

-> Based on these, I'd propose we change

   An important element in assessing security of PANA design and
   deployment in a network is the presence of lower-layer (physical and
   link-layer) security.  In the context of this document, lower-layers
   are said to be secure if they can prevent eavesdropping and spoofing
   of packets.  Examples of such networks are physically-secured DSL
   networks and 3GPP2 networks with cryptographically-secured cdma2000
   link-layer.  In these examples, the lower-layer security is enabled
   even before running the first PANA-based authentication.  In the
   absence of such a pre-established secure channel prior to running
   PANA, one needs to be created after the successful PANA
   authentication using a link-layer or network-layer cryptographic
   mechanism (e.g., IPsec). 

-> To

   An important element in assessing security of PANA design and
   deployment in a network is the presence of data origin authentication, 
   integrity and replay protection by the lower-layers. In some networks,
   this level of security is already enabled even before running the 
   first PANA-based authentication.  In the absence of such a 
   pre-established secure channel prior to running PANA, one needs to be
   created after the successful PANA authentication using a link-layer or
   network-layer cryptographic mechanism (e.g., IPsec).



I am uncomfortable with the recommendation of eap methods like md5
even when link security is available.  Can you please work with the
EAP and EMU working groups and see if they support this recommendation
in the framework document?


-> We didn't really mean to recommend use of any EAP method. For that, we
shall remove the statement "For example, weak authentication methods, such
as EAP-MD5, may be used for such networks but not for the others." 




Comment [2007-06-21]:
The PANA protocol document says that the derivation of keys for use in
setting up or binding to link or layer 3 security is out of scope.
That's fine and probably even a good idea.  however there needs to be
a single document that specifies this derivation that all the uses of
the PANA SA end up referring to.  IT would be inappropriate for the
PANA IPsec document to use one method and say a method to set up
preshared secrets for 802.11I to use another mechanism that might
interact badly with the ipsec mechanism.

-> Would the following take care of this?

-> Currently

PANA_AUTH_KEY = prf+(MSK, PaC_nonce|PAA_nonce|Session_ID|Key_ID)

-> We could change this to:

PANA_AUTH_KEY = prf+(MSK, PaC_nonce|PAA_nonce|Session_ID|Key_ID)
PANA_SECASSOC_KEY = prf+(PANA_AUTH_KEY, Key_Name)

-> The PANA_SECASSOC_KEY SHALL be used as the root key for any secure
association key management for securing link-layer or network-layer. Key_
Name is a string and it SHALL be assigned by a separate specification that
describes how PANA-generated keys are used with the specific secure
association protocol (e.g., "SECURE ASSOCIATION ROOT KEY FOR IKE-IPSEC",
"SECURE ASSOCIATION ROOT KEY FOR IEEE 802.11I".) 

-> We also need to change Section 11.5 accordingly (last sentence
especially).

-> Does this make sense?

Thank you.

Alper




_______________________________________________
Pana mailing list
Pana at ietf.org
https://www1.ietf.org/mailman/listinfo/pana