Subject: Re: [Pana] Some comments about PANA drafts

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 31 May 2004 21:02:12 -0700

Hi Pari,

Thank you for reviewing the drafts.  I have one quick comment on the
PANA framework draft.

On Mon, May 31, 2004 at 12:41:17PM +0300, [email-masked] wrote:
> 
> 
> Comments about draft-ietf-pana-framework-00:
> 
> Section 10.2.2: First, let's say that I have some doubts about
> whether anyone will actually implement this. It also seems that
> there are not enough details about e.g. PANA would actually work
> together with 802.11 and .11i state machines and procedures, but
> maybe this isn't necessary in a "framework" document. (BTW, the
> 4-way handshake is started by the AP; bullet 4 in 10.2.2.2 seems
> to assume otherwise.)

An update to section 10.2.2 is being discussed on the mailing list:

http://www1.ietf.org/mail-archive/web/pana/current/msg00693.html

(Any comment on the above thread is appreciated.)

There is some plan to implement the model in Open Diameter project.

You are right that 4-way handshake is started by the AP and bullet 4
in 10.2.2.2 is ambiguous on it.  We will revise the text.

Regards,

Yoshihiro Ohba

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

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 1 Jun 2004 12:47:17 -0700

Pasi,

Thanks for your comments. I will address the IPsec issue here :

>Comments about draft-ietf-pana-ipsec-03:
>
>Section 5: What happens if there were two EAP authentications,
>resulting in two AAA-Keys?

Do you know what happens in 802.11i  for this case ? We can follow
the same here.

>Section 8: The special rule for PANA_PORT should be included 
>in Section 8.1 and 8.2, rather than described separately.

Okay. I was trying to save space :-)

>Also, inbound SPD/SAD entries don't contain outer IP addresses.

It is more of a symmetric representation of EP's outbound SPD entry
matching PaC's inbound SPD entry and vice-versa. In terms of policy
enforcement for each packet after decryption, i agree that
the outer address don't make sense for tunnel mode. But SPD also is 
consulted to see whether i as the receiver can negotiate keys with the
initiator or not. In that sense, the SPD's outer address makes sense.

-mohan

---

From: Alper Yegin <[email-masked]>
Date: Tue, 08 Jun 2004 14:50:41 -0700

Hi Pasi,

Thank you for the review and the feedback. Let me walk through your
comments on the pana-pana-04 document.

> Comments draft-ietf-pana-pana-04:
> 
> The document would probably benefit from explaining the "big
> picture" first, e.g. what PANA messages are sent in a typical
> situation (something like Section 4.6), and only then specific
> details such as contents of PANA SA, calculation of MAC AVP and
> processing of the S-flag.

Right. We should beef up Section 3. [we shall open an issue on this and
track it]

> Section 4.1.5: Key derivation seems to assume that the integrity
> protection algorithm needs at most 160 bit key (so if some new
> algorithm later needs more, also the key derivation needs to be
> updated).

N=160 is based on the selected integrity algorithm, HMAC-SHA1. If the
algorithm changes, we need to change N as well. Since an algorithm
change would require a spec change anyways, I think setting the N value
should be fine in this document. 

> Section 4.2: HMAC-SHA1 takes two parameters, not one

OK, we shall fix that [another new issue].

> 
> Section 6.3: Diameter uses SMI enterprise numbers for Vendor-Id;
> does PANA use that also, or does it define its own number space?

Yes. We shall spell this out in the document [a new issue].

> Section 6.5.5 (Protection-Capability): Is it assumed that only a
> single L2 mechanism can exist? Or that if multiple L2 mechanisms
> are possible, the correct one can be determined from some L2
> messages?

The latter. It is assumed that a shared key is sufficient to bootstrap
L2 ciphering. 

> Section 6.5.13 (Provider-Identifier): What the client is
> supposed to do with this information? 

This is used for ISP discovery and selection. And also separating ISP
authentication from NAP authentication, when needed. These are discussed
in Section 4.2 Discovery and Initial Handshake Phase

> (And usually the
> enterprise numbers are used to identify vendors, not network
> operators--but of course a network operator could get an
> enterprise number as well...)

Hmmmm, we should verify that.....

> 
> Section 7: The retransmission behavior seems quite complicated;
> IMHO it would have been simpler to have one end (probably PaC)
> to be responsible for all timer-based retransmissions.

OK, let us look into this.

> 
> Section 9: Overall, this section is quite heavy reading, and
> it's not clear that someone not very familiar with PANA, EAP,
> etc. can actually get a very accurate picture of the relevant
> security properties of PANA. So this section would certainly
> benefit from some editorial work.

I agree [hence, a new issue for the tracker].

> 
> Part a (discovery message exchange) should probably explain that
> if including Protection-Capability and PPAC AVPs in PSR is not
> recommended, why are they allowed at all (especially since it
> seems the client won't actually need the information until PBR
> anyway).

The recommendation is for networks that are susceptible to spoofing.
Other types (e.g., physically secured networks) can use them.

> This section should also mention that any information in PANA
> messages before PBR/PBA (such as ISP-Information) can be
> spoofed, and the implications of that. 

OK.

>(BTW, perhaps it would
> have been a good idea to integrity protect all previous PANA
> messages in PBR/PBA.)

Hmmm, sounds a little too heavy weight. Is this a generally recommended
behavior for EAP lower layers?

> 
> It should be clarified what exactly is meant when it's said that
> a network is already "secure" before PANA is run. E.g. it seems
> that such networks should have reasonably reliable disconnect
> indications? What about ppreventing IP address spoofing?

Yes, we should briefly expand that. Spoofing and eavesdropping should be
prevented. Disconnect indication is needed unless the lower-layer
security is based on a crypto scheme. IP address spoofing is not needed.
[a new issue for the tracker].

> 
> References: Some of the normative references should probably be
> informative (e.g. EAP-TLS).

OK. [issue tracker]

Thank you.

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 15 Jun 2004 05:53:06 -0700

> Do you know what happens in 802.11i  for this case ? We can follow

In IEEE 802.11i there is no case that derives two AAA-Keys, so PANA
has to define its own solution.

It might be better to introduce some key derivation key (e.g.,
PANA_KD_KEY) in PANA specification draft so that each protocol that is
bootstrapped from PANA (e.g., IPsec and IEEE 802.11i PSK mode) does
not need to consider the double AAA-Key case.  Instead, it should be
the PANA_KD_KEY derivation algorithm that takes the double AAA-Key
case into account.

Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 15 Jun 2004 07:07:12 -0700

> OK, we shall fix that [another new issue].

Fixed.  (it will appear in -05b snapshot)

> Yes. We shall spell this out in the document [a new issue].

I think PANA should use SMI enterprise numbers for Vendor-Id as
Diameter does.

How about changing:

"
   Vendor-Id

      The Vendor-Id field is present if the 'V' bit is set in the AVP
      Flags field.  The optional four-octet Vendor-Id field contains the
      uniquely assigned id value, encoded in network byte order.  Any
      vendor wishing to implement a vendor-specific PANA AVP MUST use
      their own Vendor-Id along with their privately managed AVP address
      space, guaranteeing that they will not collide with any other
      vendor's vendor-specific AVP(s), nor with future IETF
      applications.
"

to:

"
   Vendor-Id

      The Vendor-Id field is present if the 'V' bit is set in the AVP
      Flags field.  The optional four-octet Vendor-Id field contains the
      IANA assigned "SMI Network Management Private Enterprise Codes"
      [ianaweb] value, encoded in network byte order.  Any
      vendor wishing to implement a vendor-specific PANA AVP MUST use
      their own Vendor-Id along with their privately managed AVP
      address space, guaranteeing that they will not collide with any
      other vendor's vendor-specific AVP(s), nor with future IETF
      applications.
"

> The latter. It is assumed that a shared key is sufficient to bootstrap

Should a specific text be added to the PANA document on this?

> OK, let us look into this.

Please see my other email on this.

> behavior for EAP lower layers?

No, not recommended.  I think it would be difficult for any protocol
that do not run on top of reliable transport to exactly maintain a
consistent view of all previous messages (including sequence numbers)
that were actually received by the peering entities.

> > informative (e.g. EAP-TLS).

Fixed.  (it will appear in -05b snapshot) Any other references that
should be marked as informative?

Yoshihiro Ohba

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 15 Jun 2004 11:08:26 -0700

> has to define its own solution.
Oh! the question was about NAP and ISP authentication ? I mis-understood
the question..

> the PANA_KD_KEY derivation algorithm that takes the double AAA-Key
This makes sense. How is the key derived for PANA SA today when there
are two authentications ? Something similar should work here.

-mohan

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 16 Jun 2004 10:57:34 -0700

> are two authentications ? Something similar should work here.

PANA_MAC_KEY, which is used for PANA SA, is derived in the following
way:

In case of single AAA-Key:

      PANA_MAC_KEY = The first N bits of
                     HMAC_SHA1(AAA-Key, ISN_pac | ISN_paa | Session-ID)

In case of double AAA-Key:

      PANA_MAC_KEY = The first N bits of
                     HMAC_SHA1(AAA-Key1 | AAA-Key2, ISN_pac | ISN_paa |
                               Session-ID)

We could modify the algorithm to derive both PANA_MAC_KEY and PANA_KD_KEY
as follows:

In case of single AAA-Key:

      {PANA_MAC_KEY | PANA_KD_KEY} = 
                      The first N+M bits of
                      HMAC_SHA1(AAA-Key, ISN_pac | ISN_paa | Session-ID)

In case of double AAA-Key:

      {PANA_MAC_KEY | PANA_KD_KEY} = 
                      The first N+M bits of
                      HMAC_SHA1(AAA-Key1 | AAA-Key2, ISN_pac | ISN_paa |
                                Session-ID)

PANA_MAC_KEY have a length of N bits.
PANA_KD_KEY have a length of M bits.

N depends on the integrity protection algorithm in use for PANA MAC AVP.
M is 512 (equal to the typical length of AAA-KEY or EAP MSK).

Yoshihiro Ohba

---

From: Alper Yegin <[email-masked]>
Date: Tue, 29 Jun 2004 16:03:45 -0700

This looks good to me.

>       their own Vendor-Id along with their privately managed AVP
address