[Pana] RE: Sam's IESG comments

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

>     Sam> What must a receiver do if it receives a PANA message with
>     Sam> unknown version?  How is the version field actually useful?
>     Sam> (How do you get backward compatibility if you discard packets
>     Sam> 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.
> 
> This is what I was afraid of.
> I implement two versions.
> How do I distinguish you not implementing my preferred version from
> network trouble?

I guess this is leading to something like "version discovery and
negotiation". We certainly don't have such a thing in our documents. 
I don't remember any WG discussion about the version number and how it is
intended to be used.

How about if we leave "version discovery and negotiation" to future
versions? Does this make sense, or would you recommend something else?


>     Sam> The framework document says that sometimes a PAC is expected
>     Sam> to reconfigure its address after PANA.  The PANA protocol has
>     Sam> no normative discussion of this.  In order to get
>     Sam> interoperable implementations, you need to clearly indicate
>     Sam> when address configuration is required.  Perhaps you are
>     Sam> deferring this to future documents.  If so, then the
>     Sam> framework should indicate that unless a PAC implements a
>     Sam> protocol extension that mandates address reconfiguration and
>     Sam> that protocol extension is used, then the PAC need not do
>     Sam> address configuration.  Or, if address reconfig is supported
>     Sam> in the base protocol, you need to have normative language
>     Sam> 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)?
> 
> As I mentioned my preference is that you drop the IP address
> reconfiguration for now and handle it in an extension when needed.
> However if you need IP configuration then yes I think this is a fine
> approach.  I understand we'll have to sell this to Mark if we go that
> route.

OK. Will follow up under the other thread.

> 
>     -> 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.
> 
> This is fine text, and I support adding it.  However since my
> understanding of the current text ended up being correct I also think
> the current text is OK.

OK.

> 
> 
> 
> 
> 
>     Sam> Section 5.5 of the protocol document should include a rule
>     Sam> that messages expected to have an auth attribute but which do
>     Sam> not do so MUST be discarded.  You need to specify which
>     Sam> messages are expected to have auth attributes (presumably all
>     Sam> of them after a completed authentication with an EAP method
>     Sam> 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.
> 
> 
> 
> >    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.
> 
> Works for me.
> 
> 
> 
>     Sam> I'm particularly concerned that even if the algorithm AVP is
>     Sam> sufficient, you recommend against using it unless the link is
>     Sam> secured.  That seems highly problematic; protected
>     Sam> 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?
> 
> Yes, I think the warning is problematic.  I think Yoshi's approach is
> reasonably good.

OK. We shall remove the warning, and implement Yoshi's approach.


> 
>     Sam> I am uncomfortable with the claim in the protocol document's
>     Sam> security consideration section that physical security
>     Sam> provides protection of confidentiality and spoofing.  I'm not
>     Sam> really sure that is true in any reasonable sense for DSL
>     Sam> lines.  I think a better way to state this is that the
>     Sam> environment provides adequate protection against spoofing and
>     Sam> confidentiality based on the operational needs of the
>     Sam> environment.
> 
>     Sam> Similarly, I'm concerned that the blanket claim that if a
>     Sam> link does not provide security then security is required at a
>     Sam> higher layer.  I agree that PANA integrity protection is
>     Sam> required, but for example I don't see why data origin
>     Sam> authentication or connectionless integrity is required for
>     Sam> most Internet traffic.  I think the security considerations
>     Sam> section could be reworked to talk a lot more about tradeoffs
>     Sam> and a lot less about hard requirements.  Some hard
>     Sam> 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.
> 
> I'm not sure this is true in practice.  I'm sitting at a wireless
> hotspot.  I log into a web page and give them my credit card number.
> MAC address seems to be good enuogh.  It does not provide data origin
> authentication, but it seems to be operationally good enough.

Yes it's true that many users and hotspot operators are using such a scheme
(UAM -- Universal Authentication Method) everyday. It's very "practical"
because it does not require any special client (just web browser), but it's
"security is very weak." The only reason it's being used (and widely used!)
is that the operators cannot practically install 3rd party software on the
client base. And they (and unknowingly the users) trade a lot of security
for a lot of practicality. 

More specifically, anyone can impersonate your PC and spoof and consume
traffic on your behalf. And anyone can impersonate the wireless hotspot and
spoof and consume traffic on its behalf. (And that effectively negates the
whole idea behind "access authentication.") These threats are possible
because there is no cryptographic protection (data origin auth) of the data
traffic after the client and the network authenticated each other. 

The next step from UAM would be to use an EAP-based solution. The
appropriate client software would include EAP methods, EAP, EAP lower layer
(IEEE 802.11i, IEEE 802.16e PKMv2, PANA, etc.), L2/L3 per-packet crypto
protection, etc. Hosts with such a package would naturally utilize data
origin authentication. 

 
>     -> 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).
> 
> 
> 
> See above.
> 
>     Sam> I am uncomfortable with the recommendation of eap methods
>     Sam> like md5 even when link security is available.  Can you
>     Sam> please work with the EAP and EMU working groups and see if
>     Sam> 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."
> 
> Works for me.
> 
> 
> 
> 
>     Sam> Comment [2007-06-21]: The PANA protocol document says that
>     Sam> the derivation of keys for use in setting up or binding to
>     Sam> link or layer 3 security is out of scope.  That's fine and
>     Sam> probably even a good idea.  however there needs to be a
>     Sam> single document that specifies this derivation that all the
>     Sam> uses of the PANA SA end up referring to.  IT would be
>     Sam> inappropriate for the PANA IPsec document to use one method
>     Sam> and say a method to set up preshared secrets for 802.11I to
>     Sam> use another mechanism that might interact badly with the
>     Sam> ipsec mechanism.
> 
>     -> Would the following take care of this?
> 
> I'm not asking for a change.
> I'm just making a note about future work.
> 
>     -> 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".)
> I don't object to this change, but don't think it is necessary provided
> you do this work somewhere before using the keys.
> I think a change of this type would require a new ietf last call.

OK, let's deal with this in a separate document.


> 
> 
>     -> We also need to change Section 11.5 accordingly (last sentence
>     Sam> especially).
> 
>     -> Does this make sense?

Alper



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