Hi, Alper,
(adding the security ADs as a heads-up on the last item in this note, just
because we're less than a week away from the telechat date for this
document).
Hi Spencer,
Mark said if we can revise the spec by Monday, he can pass the revision to
the IESG. Otherwise I guess either we miss this IESG call or do your
revision along with IESG one...
As long as you're talking to Mark, we're good.
I think we're well within the range of what the IESG can do with RFC Editor
notes (as things turned out, I think my original review comments could have
been handled this way, although sending the RFC Editor a clean draft is
always less error-prone).
Again, thanks for the quick feedback.
>> 4.1. Authentication and Authorization Phase
>>
>> The PAA SHOULD limit the rate it processes incoming PANA-Client-
>> Initiation messages to provide robustness against denial-of service
>> (DoS) attacks. Details of rate limiting are outside the scope of
>> this specification.
>>
>> Spencer: Two concerns here - why is this a SHOULD, instead of a MUST
(why
>> would you NOT do this?), but more importantly, I'm not sure how you
>> normatively require PAAs to do something that isn't described (how
would
>> you
>> know if the PAA is not doing this?)
>
> You are right. It is meant to be a recommendation. Would we say "It is
> recommended that the PAA limits the rate ...."?
This is actually a good TSV question, but what *I* was thinking was that
"rate limiting" is often described in more specific terms (like not
sending
errors more than once per second, etc.). If there's a rate you have in
mind,
it would be helpful for implementers to know that.
Sorry, I have no specific recommendation. This is merely saying "remember
to
use rate limiting." If you think this is not worth saying because it is
obvious and in the absence of any specific guidance not that useful, we
can
remove it. I'd not have any issues with that.
If we cannot decide now, let's take it to IESG review and decide there.
Actually, if Jari is happy, I'm happy. This is why your TSV Advisor gets the
big bucks :-)
>> 8.6. Result-Code AVP
>>
>> PANA_AUTHENTICATION_REJECTED 1
>>
>> Authentication has failed. When this error is returned, it is
>> assumed that authorization is automatically failed.
>>
>> Spencer: this is not entirely clear to me. Is it saying "the requestor
>> can
>> assume that authorization has also failed"?
>
> Yes, that's what we meant to say.
>
>> which still seems odd to me -
>> if
>> you're not the entity you claim to be, how could this not be true?
>> Mumble.
>
> Yes, it is always true that if the authentication fails, the client
cannot
> be authorized for the service.
>
> But see, the reverse is not true. Even if the authentication succeeds,
the
> authorization may fail for various reasons (e.g., joe is not allowed to
> access the corporate network on the weekends).
That makes perfect sense to me. The text seems to be saying "well, the
authentication failed, but just in case, we checked authentication,
too" -
that's what confused me.
You mean "we checked authorization"? The latter is "authorization."
How about:
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.
>> 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.
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
