Algorithm negotiation [was Re: [Pana] Sam's IESG comments]

[Yoshihiro Ohba <yohba at tari.toshiba.com>]

I agree with Sam's suggestion.  My detailed analysis and remedy is
shown below.

It is true that in the current PANA specification, neither the PAA
offers multiple choices of algorithms nor the PaC is allowed to tell
the PAA the algorithms it supports.  The PAA forces the PaC to use a
single set of algorithms (one for integrity algorithm and the other
for PRF) in a particular PANA session.  In that sense, there is no
algorithm negotiation mechanism defined for PANA.  The PAA can
indicate which set of algorithms needs to be used by the PaC in the
first (unprotected) PANA-Auth-Request message so that the PaC can
decide to continue the PANA session, but this is not a full algorithm
negotiation.  I fully understand Sam's concern on how a smooth
migration from an old algorithm to a new one can be done.

I think we should follow Sam's suggestion to define a mechanism for
algorithm negotiation.  As Sam commented, this requires a mechanism to
protect the negotiation (after a PANA_AUTH_KEY is generated) to make
sure we don't introduce a bidding down attack here.  (Note that in a
bidding down attack, an attacker can modify the list of algorithms
offered by the PAA to swamp the PaC to agree upon a weaker algorithm).
Here is how it works without adding much complexity.

[1] Split Algorithm AVP into two: Integrity-Algorithm AVP and
PRF-Algorithm AVP, where each AVP contains a single Unsigned16 integer
value.

[2] The algorithm negotiation is performed in the initial PAR-PAN
exchange (with the 'S' bit set).  When a PANA SA is needed, the
initial PAR MUST contain one or more Integrity-Algorithm AVPs and one
or more PRF-Algorithm AVPs supported by the PAA.  The initial PAN sent
in response to such a PAR contains only one Integrity-Algorithm AVP
and only one PRF-Algorithm AVP supported and chosen by the PaC.

[3] When a PANA SA is needed, in the final PAR-PAN exchange of the
authentication and authorization phase (with 'C' bit set), the PAR
contains only one Integrity-Algorithm AVP and only one PRF-Algorithm
AVP chosen by the PaC in the initial PAR-PAN exchange.  The AUTH AVP
contained in such PAR and PAN messages is computed differently than
that of other messages to include the initial (unprotected) PAR-PAN
exchange as follows:

      AUTH AVP value = PANA_AUTH_HASH(PANA_AUTH_KEY, PANA_PDU, 
      PANA_PDU_for_initial_PAR, PANA_PDU_for_initial_PAN)

For other messages, AUTH AVP value is computed in the same way as 
defined in the current specification:

      AUTH AVP value = PANA_AUTH_HASH(PANA_AUTH_KEY, PANA_PDU)

This way, even if an attacker alters the list of algorithms in the
initial unprotectged PAR, the alteration can be detected in the final
PAR/PAN exchange.  This mechanism would also allow future extention to
PANA to allow other types of negotiations to be peformed in the
initial PAR/PAN exchange and then protected in the final PAR/PAN
exchange.

Best Regards,
Yoshihiro Ohba


On Sun, Jun 24, 2007 at 04:53:14PM +0300, Alper Yegin wrote:
> 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
> 

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