Subject: [Pana] RE: Gen-ART Review of draft-ietf-pana-pana-15

From: "Alper Yegin" <[email-masked]>
Date: Sat, 16 Jun 2007 12:34:33 +0300

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...

> >> 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.

> >>    If the PAA wants to stay stateless in response to a
> >>    PANA-Client-Initiation message, it SHOULD NOT include an EAP-Payload
> >>    AVP in the initial PANA-Auth-Request message, and it SHOULD NOT re-
> >>
> >> Spencer: both of these SHOULDs seem odd - aren't you just saying "if
> you
> >> want to be stateless, here's how that works"? instead of normative
> >> language...
> >>
> >
> > Is using lower-case "should" sufficient?
> 
> I still think you're simply defining stateless operation. I'm thinking
> "doesn't include"/"doesn't". Does that make sense?

That's better.

> 
> >> 7.  PANA Messages
> >>
> >>    Every PANA message defined MUST include a corresponding ABNF
> >>
> >> Spencer: this is probably not a 2119 MUST, I think.
> >>
> > I agree. We should use "must."
> 
> I'm thinking something like "PANA message definitions include a
> corresponding ..." - sometimes it's just a definition, not so much a
> requirement or command.

Certainly better!

> 
> >> 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...

> 
> 
> >> 10.2.2.  Message Type
> >>
> >>    The Message Type namespace is used to identify PANA messages.
> Values
> >>    0-65,519 are for permanent, standard message types, allocated by
> IETF
> >>    Consensus [IANA].  This document defines the Message Types 1-4.  See
> >>    Section 7.1 through Section 7.7 for the assignment of the namespace
> >>    in this specification.
> >>
> >>    The values 65,520 and 65,535 (hexadecimal values 0xfff0 - 0xffff)
> are
> >>
> >> Spencer: is this two values, or a range of values? I'm confused by
> "and"
> >> versus "-". Shouldn't these two clauses match?
> >
> > True. We shall use "-" for both.
> 
> Now that I know what the sentence is saying, I'd even suggest "The range
> of
> values ...", just so it's blindingly clear.

Good idea.

> 
> 
> >> 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.

> Thanks for the quick response, and again, I'm sorry my review was later
> than
> it should have been. See you in Chicago?

Not a problem at all! See you in Chicago.

Alper

> Spencer

_______________________________________________
Pana mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pana

---

From: "Alper Yegin" <[email-masked]>
Date: Sat, 16 Jun 2007 22:47:15 +0300

Spencer,

Thanks for the quick responses -- over the weekend!

> 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.

> 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
>

---

From: Mark Townsley <[email-masked]>
Date: Mon, 18 Jun 2007 11:54:48 +0200

Spencer Dawkins wrote:
> 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,
>>
> 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).
Right, I prefer to get documents as close to finished before the IESG 
reads it, as well as before it goes to the RFC Editor. Editor's notes 
are not something I like to rely on for more than a few tweaks. Given 
the speed in which Spencer, Yoshi and Alper seemed to be operating here, 
I thought that a new version by today would be a reasonable goal to 
shoot for. I'll let the IESG know that the new version is out.

Thanks,

- Mark