Subject: [Pana] NAT traversal

From: Alper Yegin <[email-masked]>
Date: Tue, 15 Mar 2005 16:51:21 -0800

At IETF62, we decided if we can handle NAT traversal in a clean and easy
way, we shall do it. Otherwise, we will fall back to a "NATs not
supported".

Please see slides 8 and 9 on
http://panasec.org/IETF62/IETF62-PANA-mhop.ppt.

A- Issue with IP address payloads
 
  A.1- PaC DI vs. source IP address check:
   
    Earlier on the mailing list we had decided to drop this 
    integrity check, as it was making a failed attempt at solving
    another problem (IP address ownership).

    PANA can run between the PaC and PAA using whatever PaC IP 
    address appears to PAA. The PaC's DI will be set to the IP
    address that is physically configured on the PaC. And that's
    the address conveyed to the EP from PAA. And that should work
    fine (think IKE and IPsec between the PaC and EP).

  A.2- IP-Address AVP used by PaC:

    PaC sends that only when it reconfigures a POPA and replaces
    PRPA with POPA. Similar to A.1, this should work fine.

  A.3- IP-Address AVP used by PAA:

    I couldn't figure out why we needed this. Unless someone has 
    an idea, I think we not send this AVP from PAA. 

B- Destination port issue

   The PAA sets the destination port to PANA_port on the requests it 
   sends to the PaC. In that case, the NAT will fail to map the
   request message to a PaC behind it.

   We can solve this issue by stating:

   - The destination port must be set to PANA_port only when the sender
     does not know the peer's port number. After the initial exchange,
     both the PaC and PAA will know each other's port numbers.
Subsequent
     exchanges must use those ports as source and destination.

     Assumption is that, the PANA session will start by a PDI sent by
the 
     PaC.

Though these looks like simple steps to enable NAT traversal, are they
really sufficient? Are they other issues we are missing?

Alper

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

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 17 Mar 2005 10:16:33 -0800

>     fine (think IKE and IPsec between the PaC and EP).
The pana-ipsec draft says that the PRPA is sent to the EP along with other
parameters. Perhaps that can be fixed to say "device identifier is sent to
the EP".  

> really sufficient? Are they other issues we are missing?
Here are the couple of other questions that i had..

1) The NAT mapping of the PaC address might timeout. This means that the
     IP address of the PaC seen by the PAA might change over a period of time unless
     some keepalives are sent. I don't know whether this is a problem or not.
     PAA can still use the session-id to locate the session. If so, does the changing
    IP address cause problems ? Do we need keepalives ?

2) In RFC3580 (802.1x radius usage guidelines), it says that the calling-station-id
    is the supplicant's MAC address. This is not true anymore with multi-hop PANA.
    With NAT, the same happens with IP address. In 802.11i, AFAIK, the supplicant's
     MAC address is not included in PMK derivation and only used later in the 4-way
     association protocol. This is not a problem for PANA because the device-ID (MAC address)
     gets passed before the 4-way association protocol is run. So, not passing the
     real calling-station-id is safe today. Is this okay in general ? Just something to think
     about..

Perhaps there are others..

-mohan

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 25 Mar 2005 02:45:46 -0500

Hi Mohan,

> parameters. Perhaps that can be fixed to say "device identifier is sent to

And for more clarification it might be good to mention that the device
identifier can be different from the PRPA if there is a NAT router
between the PaC and PAA.

>     IP address cause problems ? Do we need keepalives ?

I think some sort of NAT keepalive is needed in order to support
PAA-initiated PANA message exchange such as PAA-initiated
re-authentication, PAA-initiated session termination, etc.  PANA-Ping
message exchange can work for NAT keepalive.

>      real calling-station-id is safe today. Is this okay in general ? Just something to think

What do you mean by "real calling-station-id"?

Regards,

Yoshihiro Ohba

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 28 Mar 2005 09:32:55 -0800

> Hi Mohan,
 solving
> identifier can be different from the PRPA if there is a NAT router
Okay.

> message exchange can work for NAT keepalive.
Okay.

> What do you mean by "real calling-station-id"?
The calling-station-id as seen by the NAS today where there is neither NAT nor multiple-hops.
What is the significance of calling station-id of the STA/supplicant ? For example,
 the latest key management draft seems to use it in the following way:

      AAA-Key = MSK(0,63)

      AMSK = KDF(EMSK, "EAP AAA-Key derivation for multiple attachments",
                  length)

      AAA-Key-B = prf(AMSK(0,63),"EAP AAA-Key derivation for
                  multiple attachments", AAA-Key, B-Called-Station-Id,
                  Calling-Station-Id,length)

      AAA-Key-C = prf(AMSK(0,63),"EAP AAA-Key derivation for
                  multiple attachments",AAA-Key, C-Called-Station-Id,
                  Calling-Station-Id, length)

      Where:
      Calling-Station-Id  = STA MAC address
      B-Called-Station-Id = AP B MAC address
      C-Called-Station-Id = AP C MAC address
      prf = HMAC-SHA1
      KDF = defined in Section 2.4
      length = length of derived key material

If the authenticator does not see the supplicant's calling-station-id the AAA-key-B/C
transported to the authenticator may not be the same as what the station sees, right ?

-mohan

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 29 Mar 2005 10:41:11 -0500

Hi Mohan,

When a MAC address of PaC is used as DI, the PAA can know the DI
(which turns into calling-station-id in RADIUS) by explicitly carrying
DI AVP in PBR/PBA exchange.  The explicit DI passing can be performed
even if an IP address is used as DI.  So I think there is no problem
here.

Yoshihiro Ohba

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Tue, 29 Mar 2005 09:41:19 -0800

> even if an IP address is used as DI.  So I think there is no problem

In my vague recollection of the draft, the DI is not exchanged until late in
the PANA protocol. So, any messages carried before the DI exchange
may not have the right calling station ID. 

Hmm.. For protecting the DI, you need the PANA SA which is not known until
the full EAP exchange is done. So, i don't know how you can carry the DI early on.
So, i still don't see how the radius messages carry the right calling station-id.

-mohan

---

From: Alper Yegin <[email-masked]>
Date: Wed, 30 Mar 2005 13:43:38 -0800

> The calling-station-id as seen by the NAS today where there is neither
NAT
> nor multiple-hops.
> What is the significance of calling station-id of the STA/supplicant ?

According to RFC 2865:

      Call Check          Used by the NAS in an Access-Request packet to
                          indicate that a call is being received and
                          that the RADIUS server should send back an
                          Access-Accept to answer the call, or an
                          Access-Reject to not accept the call,
                          typically based on the Called-Station-Id or
                          Calling-Station-Id attributes.  It is
                          recommended that such Access-Requests use the
                          value of Calling-Station-Id as the value of
                          the User-Name.

As I understand, this is for authorizing access based on the caller-id,
without doing any other authentication (i.e., no EAP methods run).

As such, the basic usage of calling-station-id seems not relevant to
PANA.

> For
> example,
> If the authenticator does not see the supplicant's calling-station-id
the
> AAA-key-B/C
> transported to the authenticator may not be the same as what the
station
> sees, right ?

We have a better identifiers than MAC addresses in PANA -- PANA Session
identifier, and PAA identifier (DiameterIdentity). For example these are
what we use in pana-mobopts. 

Alper

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 30 Mar 2005 14:54:19 -0800

Alper,

> what we use in pana-mobopts. 
Does this mean we need something like RFC 3580 (IEEE 802.1x RADIUS usage
guidlines) for PANA ? The pana-radius draft does not talk about these details.
If some of the RADIUS attributes (as defined today) have different meaning or don't
 have meaning in the PANA context, it should be stated somewhere. At least i thought
 the new RADIUS draft would have some of these details similar to RFC 3580.

I am not disagreeing with using better identifiers. But does this affect the details in the
key management draft ? For example, the AAA-key itself is wrapped in
AAA-token (i think) which is in turn transported to the authenticator from the
server. What is the scope of the key ? How is the scope determined i.e using
what parameters ? Is this all transparent to PANA ?

-mohan

---

From: Alper Yegin <[email-masked]>
Date: Wed, 30 Mar 2005 15:50:04 -0800

> If some of the RADIUS attributes (as defined today) have different
meaning
> or don't
>  have meaning in the PANA context, it should be stated somewhere. At
least
> i thought

Yes, that's where we shall capture these details.

> I am not disagreeing with using better identifiers. But does this
affect
> the details in the
> AAA-token (i think) which is in turn transported to the authenticator
from
> what parameters ? Is this all transparent to PANA ?

What is currently discussed in that I-D is 802.1X specific. Of course
the details will differ when we do the things for PANA. I don't see a
problem there.

I didn't quite understand what you are asking about the "AAA-Key" and
"AAA-token". Elaborate please.

Alper

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 30 Mar 2005 17:34:40 -0800

> Yes, that's where we shall capture these details.
Ok.

> the details will differ when we do the things for PANA. I don't see a
What do you mean by "when we do the things" ? What things ?
The above example might be related to pre-authentication but
not sure whether there is more to it.. see below..
 
> "AAA-token". Elaborate please.
In section 4.6 of the EAP-key-management draft, it talks about key scope
issue. For example,

     The AAA server and authenticator MAY implement additional
     attributes in order to further restrict the AAA-Key scope.  For
     example, in 802.11, the AAA server may provide the authenticator
     with a list of authorized Called or Calling-Station-Ids and/or
     SSIDs for which the  AAA-Key is valid.

What is it for PANA ? There are other interesting things in that section
and in the rest of the draft. Some look like general guidelines and some
are related to 802.1x. I am wondering whether there would be a similar
document for PANA. 

-mohan

-mohan

---

From: Alper Yegin <[email-masked]>
Date: Wed, 30 Mar 2005 19:30:46 -0800

> > > server. What is the scope of the key ? How is the scope determined
i.e
> > > using

The text you provided was about "key derivation for fast handoff",
details specific to IEEE 802.11 and IEEE 802.1X. 

We have the corresponding PANA specific design in the pana-mobopts I-D.

> What is it for PANA ? 

That text is talking about what I'd call "fine granularity
authorization," which is not specified in any detail. It's a bit
conceptual. [though even without that text, operators can still deploy
such enhanced solutions.] 

We don't have that level of authorization details in PANA either. I can
imagine a document can be produced for that.

> There are other interesting things in that section

That document is "EAP keying framework", which we inherent for PANA
(hence we shall comply), and we shall be able to extend as appropriate.
I don't see producing a similar doc for PANA, but documenting usage and
extensions in appropriate PANA documents (e.g., base spec, mobopts).

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 31 Mar 2005 04:22:48 -0500

> So, i still don't see how the radius messages carry the right calling station-id.

I am not sure if the AAA server really needs to know the
calling-station-id before the full EAP exchange is done.  (I think
that the NAS can send the calling-station-id in an Access-Request with
Service-Type = Call Check after completion of the full EAP exchange.)
In any case, details on the usage of calling-station-id for PANA
should be described in the pana-radius draft.

Yoshihiro Ohba

---

From: Rafa Marin Lopez <[email-masked]>
Date: Thu, 31 Mar 2005 14:46:14 +0200

Hi Alper...

<snip>

>>      AMSK = KDF(EMSK, "EAP AAA-Key derivation for multiple
>>    
>>
>attachments",
>  
>
>>                  length)
>>
Then generation of AAA-key-B and AAA-key-C from EAP key management 
framework should be changed for PANA case. What I-D should treat this issue?

On the other hand, I was wondering if AAA generates keys for diferent 
PANA agents as EAP key management framework explains for different APs 
then modifications to be included would be :

AAA-Key-B-PAA = prf(AMSK(0,63),"EAP AAA-Key derivation for
                  multiple attachments", AAA-Key,B-PAA-indentifier,
                  PaC-DI,length)

B-PAA-indentifier = extracted from PANA session.

and

PaC-DI replacing Calling-Station-Id.

is it ok for you?

Regards.

-- 
------------------------------------------------------
Rafael Marin Lopez
Faculty of Computer Science-University of Murcia
30071 Murcia - Spain
Telf: +34968367645    e-mail: [email-masked]
------------------------------------------------------

---

From: Alper Yegin <[email-masked]>
Date: Thu, 31 Mar 2005 11:45:47 -0800

Changed the subject, as this thread is no longer about "NAT traversal".

> framework should be changed for PANA case. What I-D should treat this

The keying details depend on the mechanics of the optimization being
realized. For that, the relevant details are already in pana-mobopts
I-D. 

The scheme in EAP-keying-framework Section 2.3 is about a pro-active
approach. Pana-mobopts is a CT-based reactive approach. Details will
differ. We don't have to try to fit pana-mobopts to EAP-k-f Section 2.3.
They won't fit anyways.....

Alper