Subject: (radius) update to tunnel draft

From: Matt Holdrege <[email-masked]>
Date: Wed, 05 May 1999 05:34:16 -0700

Folks, sorry for this late request to the tunneling draft. But recent
deployments of L2TP have raised a very serious issue for large scale
operations. I hope that everyone understands the value of these new
attributes. I also hope you understand that they are optional and no
implementation is required to add them. Note that the MUST's are only there
if this new behavior is desired.

===========================================================================

As operational experience is gained, it has become important for
adminstrators to provide specific names to be used during tunnel
authentication.

The administration of a large network of tunnel clients (NAS) and
tunnel servers becomes very onerous, difficult and error prone.
This becomes even more difficult when an organization doesn't have
full control over a subset of tunnel servers or clients, such as when
they subcontract a portion of their network from third parties.

Some providers are selling NAS ports to other parties which in turn
buy NAS ports from multiple providers. In this situation, maintaining
the authentication database for NAS<->tunnel servers becomes a time
consuming and error prone task. These attributes provide the ability
to specify a name to be used during tunnel authentication so that a
smaller set of names needs to be maintained between any two such
partners.

These new attributes are intended to be used for authenticating the
endpoints of the tunnel. They are not intended to be used for
authenticating enduser sessions.

Because multiple units within an administrative domain may use the
same authentication name, these attributes are not globally unique
and so they cannot be used to identify the tunnel for accounting and
auditing purposes.

Note that these attribute complement (and do not replace) the normal
Tunnel-Server-Endpoint and Tunnel-Client-Endpoint attributes.

5.xx.  Tunnel-Client-Auth-Id

   Description

      This attribute specifies the name used by the client end of the
      tunnel during the authentication phase of tunnel establishment. 
      The Tunnel-Client-Auth-Id attribute MAY be included (as a hint
      to the RADIUS server) in the Access-Request packet and MUST be
      included in the Access-Accept packet if an authentication name
      different than the default is desired. It SHOULD be included in
      Accounting-Request packets which contain Acct-Status-Type
      attributes with values of either Start or Stop and which pertain
      to a tunneled session.

   A summary of the Tunnel-Client-Auth-Id attribute format is shown
   below.  The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |     Tag       |   String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
      xx for Tunnel-Client-Auth-Id.

   Length
      >= 3

   Tag
      The Tag field is one octet in length and is intended to provide
      a means of grouping attributes in the same packet which refer to
      the same tunnel. Valid values for this field are 0x01 through
      0x1F, inclusive. If the value of the Tag field is less than or
      equal to 0x1F, it SHOULD be interpreted as indicating which
      tunnel (of several alternatives) this attribute pertains;
      otherwise, it SHOULD be interpreted as the first byte of the
      following String field.  On Accounting-Request packets, the Tag
      field SHOULD be set to 0x00.

   String
      
      The String field contains the tunnel client authentication name
      in UTF-8 format.

5.xx.  Tunnel-Server-Auth-Id

   Description

      This attribute specifies the name used by the server end of the
      tunnel during the authentication phase of tunnel establishment. 
      The Tunnel-Server-Auth-Id attribute MAY be included (as a hint
      to the RADIUS server) in the Access-Request packet and MUST be
      included in the Access-Accept packet if an authentication name
      different than the default is desired. It SHOULD be included in
      Accounting-Request packets which contain Acct-Status-Type
      attributes with values of either Start or Stop and which pertain
      to a tunneled session.

   A summary of the Tunnel-Server-Auth-Id attribute format is shown
   below.  The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |     Tag       |   String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
      xx for Tunnel-Server-Auth-Id.

   Length
      >= 3

   Tag
      The Tag field is one octet in length and is intended to provide
      a means of grouping attributes in the same packet which refer to
      the same tunnel. Valid values for this field are 0x01 through
      0x1F, inclusive. If the value of the Tag field is less than or
      equal to 0x1F, it SHOULD be interpreted as indicating which
      tunnel (of several alternatives) this attribute pertains;
      otherwise, it SHOULD be interpreted as the first byte of the
      following String field.  On Accounting-Request packets, the Tag
      field SHOULD be set to 0x00.

   String
      
      The String field contains the tunnel server authentication name
      in UTF-8 format.

Table of Attributes

Access- Access- Access- Access-   Acct-
Request Accept  Reject  Challenge Request  #   Attribute
0-1     0-1     0       0         0-1      xx  Tunnel-Client-Auth-Id
0-1     0-1     0       0         0-1      xx  Tunnel-Server-Auth-Id

Note: As for all tunneling attributes, a "1" occurance means "1-32"
      instances, each with different tag values.

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Ignacio Goyret <[email-masked]>
Date: Thu, 06 May 1999 12:39:54 -0700

At 11:48 PM 5/5/99 -0700, Matt Holdrege wrote:
>What would happen in detail given the situation below?

Hi Matt,
In general, the Tunnel-*-Endpoint attributes are used to determine the
address of the peer endpoint (eg, the IP address, PVC identifier, etc.),
and potentially, the local address to be used. They are not intended
to be used for tunnel authentication.

The Tunnel-*-Auth-Id would be used by a tunnel endpoint as the
identifier to the other tunnel endpoint during the authentication phase
of tunnel establishment. Together with the Tunnel-Password, they
provide the necessary details required for tunnel authentication.

A NAS receiving an Access-Accept with a Tunnel-Client-Auth-Id could use
that value as the identifier of the client endpoint when authenticating
to the tunnel server endpoint (whose address may have been indicated
on a Tunnel-Server-Endpoint attribute).

A NAS could also use a Tunnel-Server-Auth-Id as the expected identifier
from the tunnel server endpoint and potentially refuse the tunnel if the
server responds with some other id.

Hope this helps,
-Ignacio

>>From: "Mun, Mike" <[email-masked]>
>>To: Matt Holdrege <[email-masked]>
>>Subject: RE: (radius) update to tunnel draft
>>Date: Wed, 5 May 1999 15:08:07 -0400 
>>X-Mailer: Internet Mail Service (5.5.2448.0)
>>
>>
>>Thank you for your reply. In that sense, I would assume that NAS and Tunnel
>>Server use the AUTH-ID and Tunnel Password to do authentication. What would
>>NAS and Tunnel server behave if both tunnel endpoints and tunnel-auth-ids
>>attributes are presented in an access accept packet? 
>>
>>
>>Mike 
>>	----------
>>	From:  Matt Holdrege [SMTP:[email-masked]]
>>	Sent:  Wednesday, May 05, 1999 2:44 PM
>>	To:  Mun, Mike
>>	Subject:  RE: (radius) update to tunnel draft
>>
>>	Yes, they may be used for tunnel auth to complement the existing
>>	endpoints.
>>
>>
>>	At 11:44 AM 5/5/99 -0400, Mun, Mike wrote:
>>	>Hello, Matt,
>>	>
>>	>I think your message could be a very good point to ease the
>>	>administration burden of a ISP. Are you saying that these two
>>	>attribtues can be used in absence of the tunnel end points,
>>	>so the tunnul client and server authenticate each other using
>>	>these two attributes instead?
>>	>
>>	>Your reply will be appreciated.
>>	>
>>	>Mike

-

---

From: Aydin Edguer <[email-masked]>
Date: Tue, 11 May 1999 16:34:07 -0400 (EDT)

> >>attributes are presented in an access accept packet? 

If the NAS/Tunnel-Client received both the *-Server-Endpoint and the
*-Client-Auth-Id then it would open a connection to the Endpoint and
identify itself as the Auth-Id.

If the NAS/Tunnel-Client received the *-Server-Endpoint and both the
*-Auth-Ids then it would open a connection to the Endpoint and identify
identify itself as the *-Client-Auth-Id and expect the Server to identify
itself as the *-Server-Auth-Id.

If the NAS/Tunnel-Client received all four attributes then (a) it would
need some method external to RADIUS to determine that it was supposed to
be the Tunnel-Client (if it supported both Client and Server modes) and
then (b) it would open a connection to the *-Server-Endpoint using as the
local address the *-Client-Endpoint and identify identify itself as the
*-Client-Auth-Id and expect the Server to identify itself as the
*-Server-Auth-Id.

Note that the "external method" could be simply the context that caused
the initial Access-Request to be sent.  If the NAS sent an Access-Request,
presumably it was due to an incoming call or some sort of outgoing call
request.  In either case, the decision will probably be obvious and will
not need anything other information to decide.  It might however be a
configuration parameter on the NAS.

> >>    >these two attributes instead?

No, they cannot typically be used in the absence of the *-Endpoint
information, because they are for use only for tunnel authentication
and accounting.  Without the appropriate *-Endpoint information, there
is no way to know *where* (example: IP address) to connect.

-