Spencer, Thanks for the quick responses -- over the weekend!
> > PANA_AUTHENTICATION_REJECTED 1 > > > > Authentication has failed. When authentication fails, > authorization > > is automatically considered to have failed. > > > > Sorry, I couldn't come up with anything better... > > I'm still struggling with "automatically" (this is a lot less technical > than > you think!). "is also considered to have failed" seems more accurate to me, > but this isn't a big deal. That sounds good. > > >> >> 11. Security Considerations > >> >> > >> >> 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, one needs to be > >> >> created in conjunction with PANA using a link-layer or > >> >> network-layer > >> >> cryptographic mechanism (e.g., IPsec). > >> >> > >> >> Spencer: is this saying that you expect people to be able to set up > an > >> SA > >> >> before they start doing PANA? Does that seem realistic? > >> > > >> > There are such networks where some kind of lower-layer security > exists > >> > even > >> > before L3 authentication. For example, in cdma2K networks, L2 is > >> > already > >> > ciphered. Nevertheless, the mobile terminal is expected to get > >> > authenticated > >> > and authorized for the L3 services separately. And in DSL networks, > >> there > >> > is > >> > already some level of physical security prior to running the L3 > access > >> > authentication. > >> > >> Yeah, I understood the L2 cases - sorry for not being clearer. What I > was > >> trying to ask was about people really setting up *IPsec* SAs before > doing > >> PANA. > > > > I cannot point at a concrete case like the L2 ones. > > I can only say we don't prevent such scenarios. > > Well, yeah, but that's like saying SIP doesn't prevent the use of IPsec, > either. There is a confusion here, and let's see if we can improve the document to prevent it. There is either a secure channel (against eaves-dropping and spoofing) prior to running PANA (as in cdma2K and DSL networks), or one has to be established after successful PANA authentication. IPsec is given as an example protocol to establish such channel after PANA. I think in your understanding IPsec was used even before PANA authentication. But that's not what the document says. If that's clear, then I'd propose a revision on the last sentence as: 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). Does this help? Alper > > I'm sorry that I'm not making myself clearer here. What I'm trying to say > is > that the L2 cases you cite make total sense to me, but if it was common to > set up IPsec SAa with arbitrary endpoints on the Internet, the world would > be a different place. The use of IPsec seems to imply that the PANA client > can easily have some ability to share a key (either symmetric or > asymmetric) > with the PAA. Maybe this is true, in the PANA case, but it's sure not that > easy in the general case - that's why I'm confused. > > As I'm typing this, I'm wondering if you would do better with a > recommendation that says basically > > "PANA clients typically know whether their first-hop is L2-secure or not. > If > the PANA client is using a first-hop link that is not L2-secure, the PANA > client SHOULD use IPsec to establish a security association before the > first > PANA-based authentication". > > If this sounds like a good idea, great; if it doesn't sound like a good > idea, I'd be more comfortable just dropping "or network-layer" and "(e.g., > IPsec)". But fortunately, you have two SEC ADs AND Russ who can tell me > that > I'm nuts, so you don't have to say it... and at least two of them have > demonstrated running code that they can tell me I'm nuts :-) > > And thanks again. I'll be scribing (silently - scribes don't talk) on this > IESG telechat and look forward to seeing this draft on the agenda. > > Spencer > _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
