Subject: Re: Requirements draft is here!

From: Paal Engelstad <[email-masked]>
Date: Mon, 4 Feb 2002 20:52:48 +0100

The requirements team has done a good job!

As a side note, I would like to comment on section 4.1.2" "PAA MAY communicate the DI associated with a PaC to other entities in the network to setup packet filters and access control state."

This obviously corresponds to the "Agent Sequence" in the AAA-arch (RFC 2904). It seems like a good way to deal with address filtering as an access control mechanism, considering that we want a solution ready shortly. The alternative "Push Sequence" would imply that PAA returned a token to the PaC. The PaC would use the token to communicate directly with the access control equipment.

However, if a user wants per-packet authentication on the other hand, wouldn't the "Push Sequence" model be better? Something similar to what is mentioned in the end of the scenario draft: PaC could use the/a key (i.e. a simple form of a token) derived from the PAA Authentication process when subsequently setting up an IKE SA with a security gateway.

Thus, wouldn't there be 2 "hooks" for access control:
For agent model: PaC provides DI
For sequence model: PAA returns session key (or token) to PaC

???

This issue definitely is not clear in my mind. Perhaps you could help me clarifying it?

Paal

> 
> Fra: "Alper E. YEGIN" <[email-masked]>
> Dato: 2002/02/04 Mon AM 01:56:07 CET
> Til: "Pana \(E-mail\)" <[email-masked]>
> Tema: Requirements draft is here!
> 
> 
> Dear PANA WG members,
> 
> I'd like to announce that PANA requirements and terminology draft
> has just been submited to the IETF editors. To expedite the discussions
> on this work, I'm providing a copy of the information on this draft and
> a pointer to the text before it is officially published:
> 
> http://yegin.org/IETF/draft-ietf-pana-requirements-00.txt
> 
> 
> Title :          Protocol for Carrying Authentication for Network
>                   Access (PANA) Requirements and Terminology
> Author(s) :  Alper E. Yegin (editor), Yoshihiro Ohba,
>                   Reinaldo Penno, George Tsirtsis, Cliff Wang
> Filename :  draft-ietf-pana-requirements-00.txt
> Pages :       10
> Date :         February 3, 2002
> Abstract:
>  
>    It is expected that future IP devices will have a variety of access
>    technologies to gain network connectivity. Currently there are
>    access-specific mechanisms for providing client information to the
>    network for authentication and authorization purposes. In addition
>    to being limited to specific access medias (e.g., 802.1x for IEEE
>    802 links), some of these protocols are also sub-optimal (e.g., PPP
>    due to its mandatory framing which is not always needed). The goal
>    of the PANA Working Group is to design a general network-layer
>    protocol to authenticate clients to the networks. The protocol will
>    run between a client's device and an agent device in the network
>    where the agent might be a client of the AAA infrastructure. The
>    protocol should be independent of the underlying access-type and not
>    overloaded with other aspects of the network access (e.g., framing).
>    This document defines the common terminology and identifies the
>    requirements for PANA.
> 
> 
> Please review this draft and provide comments/questions on the
> PANA mailing list.
> 
> Enjoy!
> 
> alper
> 
>

---

From: Reinaldo Penno <[email-masked]>
Date: Mon, 4 Feb 2002 18:58:14 -0800 (PST)

Hello,

There are a list of issues we decided to let the main
list decide. I prefer to raise them now so we get a
consensus intead of coming back after we are more dow
the raod. The first one is the multicast issue.

In the requirements it is said that.

"Device Identifier (DI) 
    
The identifier used by the network as a handle to 

...<snip>...<snip>...

At most one PANA client should be associated with a DI
on a PANA authentication agent. "
    
Given that the DI can an IP address, this means that
in the multicast case you cannot use DI as an
identifier (since several clients would be associated
with a DI), or we need to change the above definition
a little.

So the main question is: Would that be a case where
you want to grant access to all members of a multicast
group without caring to know each client individually?

regards,

Reinaldo

__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions! 
http://auctions.yahoo.com