Stephen, Glen,
"PRE/PAA security is OPTIONAL since PANA messages are designed to be
used in untrusted networks, but if cryptographic mechanism is supported,
it SHOULD be IPsec."
This is an interesting statement. Just one question: if it is not
possible to use the protocol in a secure fashion (the claim being that
MITM attacks are impossible to prevent), how is it that the protocol is
"designed to be used in untrusted networks"?
So the suggested text does assume that the pana messages are well
protected between the PaC and PAA and that the PRE is security-wise
just the same as any old router on the path.
If pana messages are actually commonly sent that are vulnerable to
some attacks on the messages themselves, then IPsec between the PRE
and PAA would add enough value that I'd want it as a SHOULD.
However, I'm told that this is not the case and so the text above
should be fine.
But if the reality differs, I'd like to know about that.
Obviously, we do not necessarily know what the reality will be with PANA
use, there is not much deployed practice to look at. I think most people
would run a cryptographically well designed EAP methods.
My point was that even with such methods, a MITM can cause PANA to fail
and network access to be prevented. This is true of many things,
including IPsec. If I'm in a position to drop selected messages, for
instance, I can prevent an IPsec tunnel from being established. Still,
we like to think that IPsec has been designed to be used in untrusted
environments. It just cannot deal with all types of attacks, just with
some. Just like PANA.
I have sent an approved message for this draft with an RFC Editor note
using Alper's suggested text. If there are further text tweaks please
handle them in AUTH48. If there is further discussion of bigger issues,
we can bring the document back for another look at the IESG.
Jari
_______________________________________________
Pana mailing list
Pana@ietf.org
https://www.ietf.org/mailman/listinfo/pana
