RFC 5176 on Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)

[[e-mail]]

A new Request for Comments is now available in online RFC libraries.

        
        RFC 5176

        Title:      Dynamic Authorization Extensions to Remote 
                    Authentication Dial In User Service (RADIUS) 
        Author:     M. Chiba, G. Dommety,
                    M. Eklund, D. Mitton,
                    B. Aboba
        Status:     Informational
        Date:       January 2008
        Mailbox:    [e-mail], 
                    [e-mail], 
                    [e-mail],  [e-mail], 
                    [e-mail]
        Pages:      34
        Characters: 79541
        Obsoletes:  RFC3576
        See-Also:   

        I-D Tag:    draft-ietf-radext-rfc3576bis-13.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5176.txt

This document describes a currently deployed extension to the Remote
Authentication Dial In User Service (RADIUS) protocol, allowing
dynamic changes to a user session, as implemented by network access
server products.  This includes support for disconnecting users and
changing authorizations applicable to a user session. This memo provides 
information for the Internet community.

This document is a product of the RADIUS EXTensions
Working Group of the IETF.


INFORMATIONAL: This memo provides information for the Internet community. 
It does not specify an Internet standard of any kind. Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 

help: ways_to_get_rfcs. For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


The RFC Editor Team
USC/Information Sciences Institute

...



--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [e-mail]
Delivery-date: Thu, 31 Jan 2008 08:55:49 +0000
Message-ID: <[e-mail]>
Date: Thu, 31 Jan 2008 09:52:07 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: 'radext mailing list' <[e-mail]>
Subject: Question about RFC 2865
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

  Section 5 (Attributes), page 25 says:

...
  Value

      The Value field is zero or more octets and contains information
      specific to the Attribute.
...

  However, the following text defining type-specific formats does not
define any circumstance under which a Value field of zero octets is
permissible.  Instead, the "string" and "text" types say:

      ...length zero (0) MUST NOT be sent;
      omit the entire attribute instead.


  This appears to be an inconsistency in the document.  Is it a problem?

  Alan DeKok.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Tue, 29 Jan 2008 17:50:58 +0000
Message-ID: <[e-mail]>
From: <[e-mail]>
To: "Beck01, Wolfgang" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: AW: [ADs] Re: RFC 5090 -- draft-ietf-radext-rfc4590bis -- Re: Problem with fixes to Appendix A
Date: Tue, 29 Jan 2008 09:50:46 -0800
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 8bit

Can the authors huddle and figure this out?  We really do want to get the 
test vectors right before publishing RFC 5090.

--------------------------------------------------
From: "Beck01, Wolfgang" <[e-mail]>
Sent: Tuesday, January 29, 2008 6:12 AM
To: <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>
Subject: AW: [ADs] Re: RFC 5090 -- draft-ietf-radext-rfc4590bis -- Re: 
Problem with fixes to Appendix A

> I hate to say it, but there are still bugs in the examples.
>
> In the Access-Request with id 0x7d, I calculate a Digest-Response of
> 958ce2c45980c79bd91c3044f32be6da
> and a Message-Authenticator of
> 92A87E1C88BD9573958327C656094634
>
> For the corresponding Access-Accept, I get an Authenticator of
> F237371FFDBFE48CBD9F63D25086B004
> a Digest-Response-Auth of
> 1e2e26caa5611b083e201778485fb394
> and a Message Authenticator of
> 51C3078093B3C5C15FACF27A27E7BE0A
>
> In the Access-Request with id 0x7e, the diff version states a packet
> length of 72. Summing up
> 20 Byte RADIUS header
> 6 Byte NAS-IP
> 6 Byte NAS-Port
> 5 Byte Digest-Method GET
> 13 Byte Digest-URI /index.html
> 18 Byte Message-Authenticator
> ---
> 68 Bytes, not 72.
>
> My script comes up with a Message-Authenticator of 
> 690BFC95E88DF3B185F15CD78E469992
>
> For the Access-Request with Id 0x7f, I calculate a
> Digest-Response of
> 5af2aae88d01277b70c03865ced2abef
> and a Message-Authenticator of
> 904890FD52DA0DEDF400B8CABD7A8642
>
> For the Accesss-Accept of Id 0x7f, I get an Authenticator of
> EB50D310D1649A0C3FCEBC2623422FCA
> a Digest-Response-Auth of
> 0414c25df396d125d79380982de80516
> and a Message-Authenticator of
> 08EBFB290D55EEA4BF8FB48405A16E55
>
> For the packets with id 0x7c, I get the same values as in the rfc doc.
>
>> -----Ursprüngliche Nachricht-----
>> Von: RFC Editor [mailto:[e-mail]]
>> Gesendet: Dienstag, 29. Januar 2008 02:38
>> An: Baruch Sterman; Dan Romascanu; Ronald Bonica
>> Cc: David Schwartz; Bernard Aboba; Beck, Wolfgang;
>> [e-mail]; David Schwartz; [e-mail];
>> [e-mail]; Dan Romascanu; Ronald Bonica;
>> [e-mail]; RFC Editor
>> Betreff: [ADs] Re: RFC 5090 -- draft-ietf-radext-rfc4590bis
>> -- Re: Problem with fixes to Appendix A
>>
>>
>> Greetings Dan and Ron,
>>
>> Please review the changes in the Appendix below and let us
>> know if you approve.
>>
>> Note that you can also review the changes to the Appendix in
>> the diff file located at:
>>
>>    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5090-last-diff.html
>>
>> All of the authors have signed off on the document, and we
>> now await your approval before announcing the document.
>>
>> Thank you.
>>
>> RFC Editor
>>
>>
>> On Tue, Jan 15, 2008 at 08:35:36PM +0200, Baruch Sterman wrote:
>> > I hope this does it!
>> >
>> >
>> >
>> > Thanks to everyone.
>> >
>> >
>> >
>> >
>> >
>> > We would like to add at the top of the acknowledgements:
>> >
>> >
>> >
>> >       The authors would like to thank Mike McCauley for his help in
>> > working through the details of the examples.
>> >
>> >
>> >
>> >
>> >
>> > Here is the full version of examples. I highlighted places
>> where there
>> > are changes:
>> >
>> >
>> >
>> >
>> >
>> >    A->B
>> >
>> >
>> >
>> >       INVITE sip:[e-mail] SIP/2.0
>> >
>> >       From: <sip:[e-mail]>
>> >
>> >       To: <sip:[e-mail]>
>> >
>> >
>> >
>> >    B->A
>> >
>> >
>> >
>> >       SIP/2.0 100 Trying
>> >
>> >
>> >
>> >    B->C
>> >
>> >
>> >
>> >       Code = Access-Request (1)
>> >
>> >       Packet identifier = 0x7c (124)
>> >
>> >       Length = 97
>> >
>> >       Authenticator = F5E55840E324AA49D216D9DBD069807C
>> >
>> >       NAS-IP-Address = 192.0.2.38
>> >
>> >       NAS-Port = 5
>> >
>> >       User-Name = 12345678
>> >
>> >       Digest-Method = INVITE
>> >
>> >       Digest-URI = sip:[e-mail]
>> >
>> >       Message-Authenticator = 7600D5B0BDC33987A60D5C6167B28B3B
>> >
>> >
>> >
>> >    C->B
>> >
>> >
>> >
>> >       Code = Access-challenge (11)
>> >
>> >       Packet identifier = 0x7c (124)
>> >
>> >       Length = 72
>> >
>> >       Authenticator = EBE20199C26EFEAD69BF8AB0E786CA4D
>> >
>> >       Digest-Nonce = 3bada1a0
>> >
>> >       Digest-Realm = example.com
>> >
>> >       Digest-Qop = auth
>> >
>> >       Digest-Algorithm = MD5
>> >
>> >       Message-Authenticator = 5DA18ED3BBC9513DCBDE0A37F51B7DE3
>> >
>> >
>> >
>> >    B->A
>> >
>> >
>> >
>> >       SIP/2.0 407 Proxy Authentication Required
>> >
>> >       Proxy-Authenticate: Digest realm="example.com"
>> >
>> >            ,nonce="3bada1a0",qop=auth,algorithm=MD5
>> >
>> >       Content-Length: 0
>> >
>> >
>> >
>> >    A->B
>> >
>> >
>> >
>> >       ACK sip:[e-mail] SIP/2.0
>> >
>> >
>> >
>> >    A->B
>> >
>> >
>> >
>> >       INVITE sip:[e-mail] SIP/2.0
>> >
>> >       Proxy-Authorization: Digest nonce="3bada1a0"
>> >
>> >            ,realm="example.com"
>> >
>> >            ,response="756933f735fcd93f90a4bbdd5467f263"
>> >
>> >            ,uri="sip:[e-mail]",username="12345678"
>> >
>> >            ,qop=auth,algorithm=MD5
>> >
>> >            ,cnonce="56593a80,nc="00000001"
>> >
>> >
>> >
>> >       From: <sip:[e-mail]>
>> >
>> >       To: <sip:[e-mail]>
>> >
>> >
>> >
>> >    B->C
>> >
>> >
>> >
>> >       Code = Access-Request (1)
>> >
>> >       Packet identifier = 0x7d (125)
>> >
>> >       Length = 221
>> >
>> >       Authenticator = F5E55840E324AA49D216D9DBD069807D
>> >
>> >       NAS-IP-Address = 192.0.2.38
>> >
>> >       NAS-Port = 5
>> >
>> >       User-Name = 12345678
>> >
>> >       Digest-Method = INVITE
>> >
>> >       Digest-URI = sip:[e-mail]
>> >
>> >       Digest-Realm = example.com
>> >
>> >       Digest-Qop = auth
>> >
>> >       Digest-Algorithm = MD5
>> >
>> >       Digest-CNonce = 56593a80
>> >
>> >       Digest-Nonce = 3bada1a0
>> >
>> >       Digest-Nonce-Count = 00000001
>> >
>> >       Digest-Response = 756933f735fcd93f90a4bbdd5467f263
>> >
>> >       Digest-Username = 12345678
>> >
>> >       SIP-AOR = sip:[e-mail]
>> >
>> >       Message-Authenticator = B6C7F7F8D11EF261A26933D234561A60
>> >
>> >
>> >
>> >    C->B
>> >
>> >
>> >
>> >       Code = Access-Accept (2)
>> >
>> >       Packet identifier = 0x7d (125)
>> >
>> >       Length = 72
>> >
>> >       Authenticator = FFDD74D6470D21CB6FC4D6056BE245D2
>> >
>> >       Digest-Response-Auth = f847de948d12285f8f4199e366f1af21
>> >
>> >       Message-Authenticator = 7B76E2F10A7067AF601938BF13B0A62E
>> >
>> >
>> >
>> >    B->A
>> >
>> >
>> >
>> >       SIP/2.0 180 Ringing
>> >
>> >
>> >
>> >    B->A
>> >
>> >
>> >
>> >       SIP/2.0 200 OK
>> >
>> >
>> >
>> >    A->B
>> >
>> >
>> >
>> >       ACK sip:[e-mail] SIP/2.0
>> >
>> >
>> >
>> >    A second example shows the traffic between a web browser
>> (A), a web
>> >
>> >    server (B), and a RADIUS server (C).
>> >
>> >
>> >
>> >    A->B
>> >
>> >
>> >
>> >       GET /index.html HTTP/1.1
>> >
>> >
>> >
>> >    B->C
>> >
>> >       Code = Access-Request (1)
>> >
>> >       Packet identifier = 0x7e (126)
>> >
>> >       Length = 78
>> >
>> >       Authenticator = F5E55840E324AA49D216D9DBD069807E
>> >
>> >       NAS-IP-Address = 192.0.2.38
>> >
>> >       NAS-Port = 5
>> >
>> >       Digest-Method = GET
>> >
>> >       Digest-URI = /index.html
>> >
>> >       Message-Authenticator = E4C3D52DD0472663B49A6623B52C2A67
>> >
>> >
>> >
>> >    C->B
>> >
>> >
>> >
>> >       Code = Access-challenge (11)
>> >
>> >       Packet identifier = 0x7e (126)
>> >
>> >       Length = 72
>> >
>> >       Authenticator = 2EE5EB01C02C773B6C6EC8515F565E8E
>> >
>> >       Digest-Nonce = a3086ac8
>> >
>> >       Digest-Realm = example.com
>> >
>> >       Digest-Qop = auth
>> >
>> >       Digest-Algorithm = MD5
>> >
>> >       Message-Authenticator = 646DB2B0AF9E72FFF2CF7FEB33C4952A
>> >
>> >
>> >
>> >    B->A
>> >
>> >
>> >
>> >       HTTP/1.1 401 Authentication Required
>> >
>> >       WWW-Authenticate: Digest realm="example.com",
>> >
>> >           nonce="a3086ac8",qop=auth,algorithm=MD5
>> >
>> >       Content-Length: 0
>> >
>> >
>> >
>> >    A->B
>> >
>> >
>> >
>> >       GET /index.html HTTP/1.1
>> >
>> >       Authorization: Digest algorithm=MD5,qop=auth,nonce="a3086ac8"
>> >
>> >            ,nc="00000001",cnonce="56593a80"
>> >
>> >            ,realm="example.com"
>> >
>> >            ,response="a4fac45c27a30f4f244c54a2e99fa117"
>> >
>> >            ,uri="/index.html",username="12345678"
>> >
>> >
>> >
>> >    B->C
>> >
>> >
>> >
>> >       Code = Access-Request (1)
>> >
>> >       Packet identifier = 0x7f (127)
>> >
>> >       Length = 176
>> >
>> >       Authenticator = F5E55840E324AA49D216D9DBD069807F
>> >
>> >       NAS-IP-Address = 192.0.2.38
>> >
>> >       NAS-Port = 5
>> >
>> >       User-Name = 12345678
>> >
>> >       Digest-Method = GET
>> >
>> >       Digest-URI = /index.html
>> >
>> >       Digest-Realm = example.com
>> >
>> >       Digest-Qop = auth
>> >
>> >       Digest-Algorithm = MD5
>> >
>> >       Digest-CNonce = 56593a80
>> >
>> >       Digest-Nonce = a3086ac8
>> >
>> >       Digest-Nonce-Count = 00000001
>> >
>> >       Digest-Response = a4fac45c27a30f4f244c54a2e99fa117
>> >
>> >       Digest-Username = 12345678
>> >
>> >       Message-Authenticator = 237D85C1478C70C67EEAF22A9C456821
>> >
>> >
>> >
>> >    C->B
>> >
>> >
>> >
>> >       Code = Access-Accept (2)
>> >
>> >       Packet identifier = 0x7f (127)
>> >
>> >       Length = 72
>> >
>> >       Authenticator = 6364FA6ED66012847C05A0895607C694
>> >
>> >       Digest-Response-Auth = 08c4e942d1d0a191de8b3aa98cd35147
>> >
>> >       Message-Authenticator = 43795A3166492AD2A890AD57D5F97D56
>> >
>> >
>> >
>> >    B->A
>> >
>> >
>> >
>> >       HTTP/1.1 200 OK
>> >
>> >       ...
>> >
>> >
>> >
>> >       <html>
>> >
>> >       ...
>> >
>> >
>> >
>>
> 

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Tue, 29 Jan 2008 09:49:56 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Bernard Aboba'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: RADEXT WG Last Call on Extended RADIUS Attributes Document
Date: Tue, 29 Jan 2008 16:48:27 +0700
Message-ID: <000901c8625c$2e6a70a0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C86296.DACBB9A0"
Thread-Index: AchhSAnMgHL29xaOROqOBPNL7+LaGAAcXTjw

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01C86296.DACBB9A0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

This is an announcement of RADEXT WG last call on the Extended RADIUS
Attributes document, prior to sending it to the IESG for consideration
as a Proposed Standard.   The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attribute
s-00.txt 
 
I'm quite surprised at this move, since even a cursory review of the
document in question would reveal that it is not at all ready for Last
Call: it is rife with gramatical errors & typos.  A cynical person might
see it as a ploy to quash debate, but maybe it's just proof that nobody
(not even WG Chairs) actually read drafts before LC.  I do wish that the
authors had been consulted on the readiness of the document, however --
it would have been polite.

RADEXT WG last call will last until February 14, 2008.  Please send
comments to the RADEXT WG mailing list ([e-mail]) in the
format described on the RADEXT WG Issues page:
http://www.drizzle.com/~aboba/RADEXT/




------=_NextPart_000_000A_01C86296.DACBB9A0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<STYLE>.hmmessage P {
	PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: =
0px; PADDING-TOP: 0px
}
BODY.hmmessage {
	FONT-SIZE: 10pt; FONT-FAMILY: Tahoma
}
</STYLE>

<META content=3D"MSHTML 6.00.6000.16587" name=3DGENERATOR></HEAD>
<BODY class=3Dhmmessage>
<DIV dir=3Dltr align=3Dleft>This is an announcement of RADEXT WG last =
call on the=20
Extended RADIUS Attributes document, prior to sending it to the IESG for =

consideration as a Proposed Standard.&nbsp;&nbsp; The document is =
available for=20
inspection here:<BR><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-at=
tributes-00.txt">http://www.ietf.org/internet-drafts/draft-ietf-radext-ex=
tended-attributes-00.txt</A><SPAN=20
class=3D359302414-28012008><FONT face=3DArial=20
color=3D#0000ff>&nbsp;</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D359302414-28012008></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D359302414-28012008><FONT =
face=3DArial=20
color=3D#0000ff>I'm quite surprised at this move, since even a cursory =
review of=20
the document in question would reveal that it is not at all ready for =
Last Call:=20
it is rife with gramatical errors &amp; typos.&nbsp; A cynical person =
might see=20
it as a ploy to quash debate, but maybe it's just proof that =
<EM>nobody</EM>=20
(not even WG Chairs) actually read drafts before LC.&nbsp; I do wish =
that the=20
authors had been consulted on the readiness of the document, however -- =
it would=20
have been polite.</FONT></SPAN><BR><BR>RADEXT WG last call will last =
until=20
February 14, 2008.&nbsp; Please send comments to the RADEXT WG mailing =
list=20
([e-mail]) in the format described on the RADEXT WG Issues =

page:<BR>http://www.drizzle.com/~aboba/RADEXT/<BR><BR><BR></DIV></BODY></=
HTML>

------=_NextPart_000_000A_01C86296.DACBB9A0--


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Mon, 28 Jan 2008 16:52:58 +0000
Message-ID: <[e-mail]>
Date: Mon, 28 Jan 2008 17:49:53 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>,  'radext mailing list' <[e-mail]>
Subject: Re: Review of RADIUS Design Guidelines document
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> Here is my review of the RADIUS Design Guidelines document:
> http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt
...
> I am not sure that these paragraphs provide a sufficiently comprehensive
> description of what would constitute a change to the RADIUS operational
> model.  For example, "Design Considerations for Protocol Extensions"
> (http://www.watersprings.org/pub/id/draft-carpenter-extension-recs-02.txt)
> provides a definition of a "major extension" in Section 3.3 that seems
> considerably broader than the considerations provided in the above
> paragraphs.  My suggestion would be to expand this section to explicitly
> list some of the basic assumptions of the RADIUS protocol. 

  Hmm... I'm trying to come up with something that the WG could agree
with, but which isn't banal to the point of being meaningless.

  The comments about the State attribute are a good start.  Other points
are:

 - RADIUS is a transport protocol for authentication credentials,
authorization information, and accounting data for user sessions
 - authorization is possible only after a session has been successfully
authenticated
 - the protocol is "hop by hop", and not "end to end"
 - all data transported by RADIUS is visible to all intermediate nodes
 - authentication servers do not have to be co-located with accounting
servers
 - no action may be taken on Access-Reject other than disconnecting the
user session that was attempting authentication
 - no information may be sent in an Accounting-Response
 - Any PDU may not reach it's intended destination.  Implementations
should be robust in the event of lost, missing, or incomplete information

  Suggestions for more?

> Given the concern about SHA-1 collisions, is it worth recommending
> against use of this algorithm in new attributes?

  Yes.

> I also something might be worth saying about the use of RADIUS without
> user authentication.

  This can be mentioned as part of the set of assumptions.

> Section 1
> 
> Suggest changing: ... To: ...

  Looks good to me.


> Section 5
> 
> Suggest changing ... To: ...

  Looks good to me.

  Alan DeKok.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Mon, 28 Jan 2008 01:17:13 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_d6d63d6d-5c47-465f-a108-502932212ec3_"
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>
Subject: Review of RADIUS Design Guidelines document
Date: Sun, 27 Jan 2008 17:16:46 -0800
MIME-Version: 1.0

--_d6d63d6d-5c47-465f-a108-502932212ec3_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Here is my review of the RADIUS Design Guidelines document:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt

Section 1.1 states:

"   The advice in this document applies to attributes used to encode
   service-provisioning or authentication data.  RADIUS protocol
   changes, or specification of attributes that can be used to, in
   effect, provide new RADIUS commands (such as Service-Type) are out of
   scope.  Since protocol changes require greater expertise and deeper
   review, such changes should not be undertaken outside the IETF and
   when handled within the IETF require "IETF Consensus" for adoption,
   as noted in [RFC3575] Section 2.1.

   As with protocol changes, this document does not provide guidance to
   document authors seeking to change the RADIUS operational model.
   While RADIUS server implementations may keep state, the RADIUS
   protocol is stateless, although information may be passed from one
   protocol transaction to another via the State Attribute.  As a
   result, documents which require stateful protocol behavior without
   use of the State Attribute are inherently incompatible with RADIUS as
   defined in [RFC2865], and need to be redesigned."

I am not sure that these paragraphs provide a sufficiently comprehensive de=
scription of what would constitute a change to the RADIUS operational model=
.  For example, "Design Considerations for Protocol Extensions" (http://www=
.watersprings.org/pub/id/draft-carpenter-extension-recs-02.txt) provides a =
definition of a "major extension" in Section 3.3 that seems considerably br=
oader than the considerations provided in the above paragraphs.  My suggest=
ion would be to expand this section to explicitly list some of the basic as=
sumptions of the RADIUS protocol. =20

Section 5

Given the concern about SHA-1 collisions, is it worth recommending against =
use of this algorithm in new attributes?=20

I also something might be worth saying about the use of RADIUS without user=
 authentication.=20

Other comments:

Section 1

Suggest changing:

"   This document provides guidelines for the design of RADIUS attributes
   both within the IETF as well as within other Standards Development
   Organizations (SDOs).  By articulating RADIUS design guidelines, it
   is hoped that this document will encourage the development and
   publication of high quality RADIUS attribute specifications.  The
   advice in this document will not be helpful unless it is put to use.

   As with "Guidelines for Authors and Reviewers of MIB Documents"
   [RFC4181], it is expected that this document will enable authors to
   check their document against the guidelines prior to requesting a
   review (such an "Expert Review" described in [RFC3575]).  Similarly,
   it is hoped that this document will be of use to reviewers (such as
   WG participants or the AAA Doctors) in improving the consistency of
   reviews.
"

To:

"   This document provides guidelines for the design of RADIUS attributes
   both within the IETF as well as within other Standards Development
   Organizations (SDOs).  By articulating RADIUS design guidelines, it
   is hoped that this document will encourage the development and
   publication of high quality RADIUS attribute specifications. =20

   However, the advice in this document will not be helpful unless=20
   it is put to use.  As with "Guidelines for Authors and Reviewers=20
   of MIB Documents [RFC4181], it is expected that this document will=20
   be used by authors to check their document against the guidelines=20
   prior to requesting review (such an "Expert Review" described=20
   in [RFC3575]).  Similarly, it is expected that this document will=20
   used by reviewers (such as WG participants or the AAA Doctors),
   resulting in an improvement in the consistency of reviews."

Section 5

Suggest changing

"The MD5 algorithm
   has recently become a focus of scrutiny and concern in security
   circles, and as a result, the use of this technique in new attributes
   is NOT RECOMMENDED."

To:

   "The MD5 and SHA-1 algorithms
   have recently become a focus of scrutiny and concern in security
   circles, and as a result, the use of these algorithms in new attributes
   is NOT RECOMMENDED."

--_d6d63d6d-5c47-465f-a108-502932212ec3_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
Here is my review of the RADIUS Design Guidelines document:<br>http://www.i=
etf.org/internet-drafts/draft-ietf-radext-design-02.txt<br><br>Section 1.1 =
states:<br><br>"<pre>   The advice in this document applies to attributes u=
sed to encode<br>   service-provisioning or authentication data.  RADIUS pr=
otocol<br>   changes, or specification of attributes that can be used to, i=
n<br>   effect, provide new RADIUS commands (such as Service-Type) are out =
of<br>   scope.  Since protocol changes require greater expertise and deepe=
r<br>   review, such changes should not be undertaken outside the IETF and<=
br>   when handled within the IETF require "IETF Consensus" for adoption,<b=
r>   as noted in [RFC3575] Section 2.1.<br><br>   As with protocol changes,=
 this document does not provide guidance to<br>   document authors seeking =
to change the RADIUS operational model.<br>   While RADIUS server implement=
ations may keep state, the RADIUS<br>   protocol is stateless, although inf=
ormation may be passed from one<br>   protocol transaction to another via t=
he State Attribute.  As a<br>   result, documents which require stateful pr=
otocol behavior without<br>   use of the State Attribute are inherently inc=
ompatible with RADIUS as<br>   defined in [RFC2865], and need to be redesig=
ned.</pre>"<br><br>I am not sure that these paragraphs provide a sufficient=
ly comprehensive description of what would constitute a change to the RADIU=
S operational model.&nbsp; For example, "Design Considerations for Protocol=
 Extensions" (http://www.watersprings.org/pub/id/draft-carpenter-extension-=
recs-02.txt) provides a definition of a "major extension" in Section 3.3 th=
at seems considerably broader than the considerations provided in the above=
 paragraphs.&nbsp; My suggestion would be to expand this section to explici=
tly list some of the basic assumptions of the RADIUS protocol.&nbsp; <br><b=
r>Section 5<br><br>Given the concern about SHA-1 collisions, is it worth re=
commending against use of this algorithm in new attributes? <br><br>I also =
something might be worth saying about the use of RADIUS without user authen=
tication. <br><br>Other comments:<br><br>Section 1<br><br>Suggest changing:=
<br><br>"<pre>   This document provides guidelines for the design of RADIUS=
 attributes<br>   both within the IETF as well as within other Standards De=
velopment<br>   Organizations (SDOs).  By articulating RADIUS design guidel=
ines, it<br>   is hoped that this document will encourage the development a=
nd<br>   publication of high quality RADIUS attribute specifications.  The<=
br>   advice in this document will not be helpful unless it is put to use.<=
br><br>   As with "Guidelines for Authors and Reviewers of MIB Documents"<b=
r>   [RFC4181], it is expected that this document will enable authors to<br=
>   check their document against the guidelines prior to requesting a<br>  =
 review (such an "Expert Review" described in [RFC3575]).  Similarly,<br>  =
 it is hoped that this document will be of use to reviewers (such as<br>   =
WG participants or the AAA Doctors) in improving the consistency of<br>   r=
eviews.<br></pre>"<br><br>To:<br><br>"<pre>   This document provides guidel=
ines for the design of RADIUS attributes<br>   both within the IETF as well=
 as within other Standards Development<br>   Organizations (SDOs).  By arti=
culating RADIUS design guidelines, it<br>   is hoped that this document wil=
l encourage the development and<br>   publication of high quality RADIUS at=
tribute specifications.  <br><br>   However, the advice in this document wi=
ll not be helpful unless <br>   it is put to use.  As with "Guidelines for =
Authors and Reviewers <br>   of MIB Documents [RFC4181], it is expected tha=
t this document will <br>   be used by authors to check their document agai=
nst the guidelines <br>   prior to requesting review (such an "Expert Revie=
w" described <br>   in [RFC3575]).  Similarly, it is expected that this doc=
ument will <br>   used by reviewers (such as WG participants or the AAA Doc=
tors),<br>   resulting in an improvement in the consistency of reviews."<br=
><br>Section 5<br><br>Suggest changing<br><br>"The MD5 algorithm<br>   has =
recently become a focus of scrutiny and concern in security<br>   circles, =
and as a result, the use of this technique in new attributes<br>   is NOT R=
ECOMMENDED."<br><br>To:<br><br>   "The MD5 and SHA-1 algorithms<br>   have =
recently become a focus of scrutiny and concern in security<br>   circles, =
and as a result, the use of these algorithms in new attributes<br>   is NOT=
 RECOMMENDED."<br></pre></body>
</html>=

--_d6d63d6d-5c47-465f-a108-502932212ec3_--

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Mon, 28 Jan 2008 00:49:06 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_42136b39-ee9d-47cc-894a-13ab72f63acc_"
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>
Subject: RADEXT WG Last Call on Extended RADIUS Attributes Document
Date: Sun, 27 Jan 2008 16:47:59 -0800
MIME-Version: 1.0

--_42136b39-ee9d-47cc-894a-13ab72f63acc_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


This is an announcement of RADEXT WG last call on the Extended RADIUS Attri=
butes document, prior to sending it to the IESG for consideration as a Prop=
osed Standard.   The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-0=
0.txt

RADEXT WG last call will last until February 14, 2008.  Please send comment=
s to the RADEXT WG mailing list ([e-mail]) in the format desc=
ribed on the RADEXT WG Issues page:
http://www.drizzle.com/~aboba/RADEXT/



--_42136b39-ee9d-47cc-894a-13ab72f63acc_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
This is an announcement of RADEXT WG last call on the Extended RADIUS Attri=
butes document, prior to sending it to the IESG for consideration as a Prop=
osed Standard.&nbsp;&nbsp; The document is available for inspection here:<b=
r>http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes=
-00.txt<br><br>RADEXT WG last call will last until February 14, 2008.&nbsp;=
 Please send comments to the RADEXT WG mailing list ([e-mail]=
) in the format described on the RADEXT WG Issues page:<br>http://www.drizz=
le.com/~aboba/RADEXT/<br><br><br></body>
</html>=

--_42136b39-ee9d-47cc-894a-13ab72f63acc_--

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Tue, 15 Jan 2008 05:32:48 +0000
Message-ID: <[e-mail]>
Date: Tue, 15 Jan 2008 06:29:37 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Glen Zorn <[e-mail]>
CC: [e-mail]
Subject: Re: Questions on modified Extended Attribute format?
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:
> Not to mention being "backward compatible", right?  Oh, wait, that is
> only a requirement for things you don't like...

  Putting the invective aside, I think you've missed much of what I've said.

 - the format AS PROPOSED IN THE DOCUMENT is OK.
   - I'm not perfectly happy with it, but it's OK
   - it leverages a format used for other purposes: that's great
   - I am fine with it not being "backwards compatible"
   - it achieved WG consensus: that's a miracle

 - The "16-bit" variant recently proposed on the list is not OK
   - it's less nice than the format in the document
   - it's yet another "magic" vsa format
   - it introduces even more incompatibilities than the other format
   - it has not acheived WG consensus
   - it throws away the consensus obtained for the other format.

  To put it bluntly: every argument FOR the 16-bit variant of the
extended format is also an argument FOR the Diameter AVP format.  If you
are going to seriously propose a 16-bit variant of the extended format,
then I think there is a contingent of this WG that would have issues
with that.

  My preference, in order of priority:

  1) extended format AS IN THE DOCUMENT
  2) Diameter AVP format
  3) 16 bit variant of the extended format

  (1) has achieved WG consensus.  (2) and (3) have not.  Can we stop
this, and just move on?

 Alan DeKok.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Mon, 14 Jan 2008 07:56:36 +0000
Message-ID: <[e-mail]>
Date: Mon, 14 Jan 2008 08:53:36 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Glen Zorn <[e-mail]>
CC: [e-mail]
Subject: Re: Questions on modified Extended Attribute format?
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:
> It hasn't changed yet, I was proposing to change it in order to provide
> greatly enhanced functionality.

  I was under the impression that the WG had mostly achieved consensus
on the format.

> How about this: leave the extra octet in there, but mark it as
> "Reserved", so at least it will be there for future use?

  If that's the proposal, then I prefer the Diameter AVP format.  It is
simpler, more flexible, and does not require the introduction of yet
another incompatible VSA format.

  Alan DeKok.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 11 Jan 2008 16:40:54 +0000
From: Avi Lior <[e-mail]>
To: "David B. Nelson" <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Fri, 11 Jan 2008 11:39:08 -0500
Subject: RE: Questions on modified Extended Attribute format?
Message-ID: <[e-mail]>
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

You are correct.  In RADIUS definitions we define attributes by specifying =
the format and meaning.

When we define the meaning typically we say when this attribute "when inclu=
ded in an access accept message it means ...." and "when included in an acc=
ess request it means ...."

Now if we want to reuse the attribute (because we love the format) in a new=
 container.  We would just have to modify the meaning part of the definitio=
n by adding "when the attribute appears as part of this grouping it means .=
.."

Going forward if you really want to promote reuse when it is possible you w=
ould just define the syntax of the attribute and then when you define the c=
ontainer (grouping) which includes that attribute you would define what it =
means when this attribute is in a particular container/grouping.

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of David B. Nelson
> Sent: Wednesday, January 09, 2008 10:43 AM
> To: [e-mail]
> Subject: RE: Questions on modified Extended Attribute format?
>
> Avi Lior writes...
>
> > An attribute can appear standalone and also be included in a group
> > (for that matter, in many groups).  The definition of the
> attribute is
> > the same in both cases, but the semantics is different right?
>
> I'm confused by this.  The "definition" of the attribute
> consists of syntax
> (format) and semantics (meaning).  What does it means to say
> that the definition is the same but the semantics (meaning)
> is different?
>
>
>
>
> --
> to unsubscribe send a message to
> [e-mail] with the word 'unsubscribe' in
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 11 Jan 2008 06:29:30 +0000
Message-ID: <[e-mail]>
Date: Fri, 11 Jan 2008 07:26:24 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Glen Zorn <[e-mail]>
CC: [e-mail]
Subject: Re: Questions on modified Extended Attribute format?
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:
> The users are being rejected because the provider of their client has
> made up his own rules about what a valid response is;

  Umm... the provider of their client is compatible with 2865, not with
the new specification allowing 2865 to be tunneled in extended
attributes.  i.e. they haven't upgraded.

  Is this permitted?  Or should we just say "too bad", and move ahead?

> Tell me the difference in effect.  As for encapsulating all the
> attributes in VSAs, that is easily handled by disqualifying the
> mandatory attributes (such as User-Name, EAP-Message, etc.) from
> inclusion.

  Then those issues need to be addressed in the extended attributes
draft.  That should triple it's size, and add another few years to the
time frame. :(

> I'm going to give you the benefit of the doubt & assume that you have
> actually read the draft & merely misspoke: the "continuation flag" is
> one bit, not one byte; the rest of that octet is the Tag field.

  I read the draft... I just don't see a need to explain what every bit
means when I'm trying to count bytes.

> Really?  The "new attribute header" that you conveniently gloss over
> above contains a 1 octet total length for the attribute, giving the same
> length limit as old-style RADIUS; of course, you could always either a)
> just concatenate "Diameter AVPs" of the same AVP type together (but then
> you can only have one AVP of a given type in a message) or b) add an
> "awkward" continuation BIT to the Flags field of the AVP...

  See Barney's comments.

> Again, I'm kind of amazed: I thought that you had implemented the WiMax
> VSAs.

  Not offically as of yet.  See the web page: no mention of WiMax.

  The Diameter stuff was easy: pack diameter AVP's (using existing
code), encapsulate in RADIUS (~50 lines of new code), etc.  The hardest
part was internal book-keeping && data structure updates.

>>   This proposal offers LESS than the "Diameter AVP in RADIUS" does,
>> at the cost of MORE work. 
> 
> See above.

  I've looked into it... the Diameter AVP stuff was easier.

> I agree completely: it is becoming rather painfully obvious (from the
> landing of red herrings (make that whales ;-), the frothing at the
> mouth, grasping at straws & confusing of implementations with standards)
> that this idea is entirely too close to useful to be approved by this
> committee.

  I thought it was that the goal-posts were changing.  Just as everyone
was resigned to accepting the format in the extended attributes draft...
it changed.

  How about this.  I'll stop arguing with the extensions to the extended
draft if you stop proposing them.  I'm willing to achieve consensus on
the basic format of the extended attributes draft:

    1 byte type
    1 byte length
    1 byte Cttttttt
    data...

  You'll note that my recent objections have NOT been to that format,
but only to the proposed extensions.

  Alan DeKok.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 11 Jan 2008 02:25:02 +0000
Date: Thu, 10 Jan 2008 21:23:40 -0500
From: Barney Wolff <[e-mail]>
To: Glen Zorn <[e-mail]>
Cc: "'Alan DeKok'" <[e-mail]>, [e-mail]
Subject: Re: Questions on modified Extended Attribute format?
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.17 (2007-11-01)

On Thu, Jan 10, 2008 at 02:52:16PM -0800, Glen Zorn wrote:
> 
> > 
> >   For a total of 10 bytes of header for one attribute.
> > 
> >   The "Diameter AVP in RADIUS" involves:
> > 
> >    new attribute header: 2 bytes
> >    Diamater header: 8 bytes (4 byte type + 4 byte length)
> 
> Pardon me: 4 byte type, 1 byte of flags (BTW, are those 8 bits of flags
> actually useful in RADIUS?) and a 3 byte length.  
> 
> > 
> >   For a total of 10 bytes.  Plus, conversion to Diameter in Diameter
> > to RADIUS gateways is easy.  We can get arbitrary grouping via the
> > Diameter method.  We can have attributes as long as we want.  
> 
> Really?  The "new attribute header" that you conveniently gloss over
> above contains a 1 octet total length for the attribute, giving the same
> length limit as old-style RADIUS; of course, you could always either a)
> just concatenate "Diameter AVPs" of the same AVP type together (but then
> you can only have one AVP of a given type in a message) or b) add an
> "awkward" continuation BIT to the Flags field of the AVP...

Well, no.  The proposal was that all the EA TLVs would be concatenated
before being decoded, so the Diameter length fields would delimit the
attributes.  No continuation bits, bytes or logic.  And of course, the
totality of EAs could/should be packed into as many full RADIUS TLVs as
necessary, with much less TL overhead.

Allow me to express some wry amusement that the pretext for rejecting
the Diameter-format proposal was that only attribute typespace exhaustion
was of interest, not attribute length or grouping.  Then, magically,
length and grouping came back.  Being retired, at least I won't have
to code whatever y'all eventually agree on.

-- 
Barney Wolff         I never met a computer I didn't like.


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Thu, 10 Jan 2008 22:53:13 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Alan DeKok'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Questions on modified Extended Attribute format?
Date: Thu, 10 Jan 2008 14:52:16 -0800
Message-ID: <000901c853db$8007d7c0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: AchR0kMNPUYWhCuSQMu0yUMgsit4YgCAzrPQ

Alan DeKok <> scribbled on Tuesday, January 08, 2008 12:32 AM:

> Glen Zorn wrote:
>> You keep saying that but I really don't know where you get this
>> funny idea. 
> 
>   New extensions cannot break existing deployments.
> 
>   This is NOT the same as saying new extensions require new code for
> implementations to support those extensions. 
> 
>>> [ re: packing standard attributes inside of extended ]
>> Only if the authentication method in use is EAP, I think.  RFC 2865
>> doesn't list any attributes as required in any type of response; if
>> your client fails because it can't find any attributes in the packet,
>> your client is broken.
> 
>   The client will reject the user, 

If it does, it is broken (modulo the above).

> or will apply the wrong policy
> (i.e. 
> default "empty response" policy, rather than the policy in the
> response).  Please explain to the user and administrator that the
> users are being rejected because of a new feature in RADIUS, and that
> this is a Good Thing.  

The users are being rejected because the provider of their client has
made up his own rules about what a valid response is; if they get the
wrong policy (or the wrong service), tell me how that is different from
a client getting tunnel attributes that it doesn't understand &
therefore ignores.
 
> 
>> Really?  Tell me what happens when a NAS receives, say, a tunnel
>> attribute that it doesn't understand; then tell me how that is
>> different from the introduction of _any_ new standard attribute and
>> how it constitutes "communication".
> 
>   The issue is NOT introduction of a new standard attribute.  The
> issue is encapsulating standard attributes that the client DOES
> understand in a VSA that the client DOES NOT understand.  

Tell me the difference in effect.  As for encapsulating all the
attributes in VSAs, that is easily handled by disqualifying the
mandatory attributes (such as User-Name, EAP-Message, etc.) from
inclusion.

> 
>> Care to expand upon that a bit?
> 
>   If you're going to increase the attribute space, AND support long
> attributes, you might as well give up and use the Diameter AVP
> format.  
> Your proposal involves:
> 
>    VSA header: 2 bytes  (type, length)
>    Vendor-Id of zero: 4 bytes
>    Extended attribute header: 3 bytes (16 bit type + length)
>    "continuation" flag: 1 byte

I'm going to give you the benefit of the doubt & assume that you have
actually read the draft & merely misspoke: the "continuation flag" is
one bit, not one byte; the rest of that octet is the Tag field.

> 
>   For a total of 10 bytes of header for one attribute.
> 
>   The "Diameter AVP in RADIUS" involves:
> 
>    new attribute header: 2 bytes
>    Diamater header: 8 bytes (4 byte type + 4 byte length)

Pardon me: 4 byte type, 1 byte of flags (BTW, are those 8 bits of flags
actually useful in RADIUS?) and a 3 byte length.  

> 
>   For a total of 10 bytes.  Plus, conversion to Diameter in Diameter
> to RADIUS gateways is easy.  We can get arbitrary grouping via the
> Diameter method.  We can have attributes as long as we want.  

Really?  The "new attribute header" that you conveniently gloss over
above contains a 1 octet total length for the attribute, giving the same
length limit as old-style RADIUS; of course, you could always either a)
just concatenate "Diameter AVPs" of the same AVP type together (but then
you can only have one AVP of a given type in a message) or b) add an
"awkward" continuation BIT to the Flags field of the AVP...

> AND the
> coding is much, much, easier.   
> 
>   I implemented the Diameter format as a test a while ago, and it was
> ~400 LoC, in part because it could leverage the existing code base of
> Diameter encapsulation/decapsulation.  I've been looking at the
> extended attribute format.  It doesn't leverage any existing code. 
> It has an awkward "continuation" byte, which means it can't use any
> of the pre-existing VSA handlers, etc.  

Again, I'm kind of amazed: I thought that you had implemented the WiMax
VSAs.  You mean that that code couldn't be leveraged?  The formats are
practically identical.
   
> 
>   This proposal offers LESS than the "Diameter AVP in RADIUS" does,
> at the cost of MORE work. 

See above.

> 
>   We've been having this argument for too long.  We need to stop NOW,
> pick a format, and move on.  The endless re-visiting of attribute
> format is holding up other key work.  

I agree completely: it is becoming rather painfully obvious (from the
landing of red herrings (make that whales ;-), the frothing at the
mouth, grasping at straws & confusing of implementations with standards)
that this idea is entirely too close to useful to be approved by this
committee.

> 
>   Alan DeKok.


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Thu, 10 Jan 2008 22:04:55 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Romascanu, Dan \(Dan\)'" <[e-mail]>, "'Alan DeKok'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Questions on modified Extended Attribute format?
Date: Thu, 10 Jan 2008 14:03:35 -0800
Message-ID: <000801c853d4$ae41d020$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: AchNvxvE95gozpjSQoKAVguApoAI+AAZAbTwAO0zArAAfwfpsA==

Romascanu, Dan (Dan) <mailto:[e-mail]> scribbled on Tuesday,
January 08, 2008 1:24 AM:

>> Glen Zorn wrote:
>> 
>>> As I said, put that way or any other way you like, ANY change is
>>> incompatible with existing deployments.  If one were to add a new
>>> "standard" attribute (in the old format or the proposed VSA-like
>>> format or any other) it would be incompatible with existing
>>> deployments. 
>> 
>>   That isn't the point.  Everyone accepts that implementations have
>> to be updated to handle new standards.
>> One of the major efforts in RADIUS has been to maintain backwards
>> compatibility with existing deployments.
>> [gwz]
>> You keep saying that but I really don't know where you get this
>> funny idea. [/gwz]
>> 
> 
> The current RADEXT charter is quite explicit about the requirements
> for backwards compatibility. 
> 
> - All RADIUS work MUST be backward compatible with existing RADIUS
> RFCs, including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579,
> and 3580.  

Yup, very true.  That's not what Alan is requiring, however: "backwards
compatibility with existing deployments"
 
--------------------
is not at all the same thing as being backward compatible with the RFCs.
The proposal I'm making is not intended (nor, I believe, is it)
incompatible with the existing RFCs.

> 
> Dan


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Wed, 09 Jan 2008 20:15:30 +0000
DomainKey-Signature: s=qcdkim; d=qualcomm.com; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:Received:Received: X-MimeOLE:Content-class:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:Date:Message-ID: In-Reply-To:X-MS-Has-Attach:X-MS-TNEF-Correlator: Thread-Topic:Thread-Index:References:From:To:Cc: X-OriginalArrivalTime; b=IC1HtR8oK+DGmq0baI91Ga3q1Ac6ti9vHQudC4Wt43xSAYjHt9b5iQax X9x/YnE7uWkuKsZSeCZAi/OImTaFttQj9lz+cLb49NBaDJrX/I6aFDE+l Kbd39MzfQCTKhfnj48jdBCMBO7eCDfAkla/mJTuvxORAV9n9T2evX5NYW c=;
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [HOKEY] a transparent proposal
Date: Wed, 9 Jan 2008 12:13:20 -0800
Message-ID: <[e-mail]>
Thread-Topic: [HOKEY] a transparent proposal
Thread-Index: AchSmGWo+cEoGD4VQiKjaxmFtvr44QAXeVKQ
From: "Narayanan, Vidya" <[e-mail]>
To: "Bernard Aboba" <[e-mail]>, "Alan DeKok" <[e-mail]>
Cc: "Hannes Tschofenig" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Bernard Aboba
> Sent: Wednesday, January 09, 2008 12:18 AM
> To: Alan DeKok
> Cc: Hannes Tschofenig; [e-mail]; [e-mail];=20
> [e-mail]
> Subject: RE: [HOKEY] a transparent proposal
>=20
>=20
> >   It is up to that domain to ensure all of it's AAA servers=20
> have the=20
> > same policy.  This includes managing state for multiple login=20
> > detection, and potentially re-auth keys.
>=20
> Doesn't this imply a significant degree of complexity?  For=20
> example, one argument for the RFC 4507 PAC is that avoiding=20
> server-side state enables better scaling and authentication=20
> performance, because RADIUS servers don't replicate TLS key=20
> state.  It's hard to reconcile that argument with the idea of=20
> having the domain keeping track of server side state.=20
>=20
> If there is a way to push that state on the peer, things=20
> would be much simpler.  For example, if the ERX exchange were=20
> to leave the peer with an NAI identifying the "local server"=20
> and corresponding key state, then the peer could use that=20
> "re-auth" NAI in subsequent requests.=20
>=20

That is what is done.  The peer performs the ERP exchange with
"rIKName@localdomain", where the "rIKName" is the name of the
reauthentication integrity key that is used to authenticate the ERP
exchange and "localdomain" identifies the domain name of the local ER
server.  For local domains that replicate key material, this domain name
may actually route to one of the multiple local ER servers; for local
domains that strictly have one server, they have the burden of providing
local domain names that are server-specific.  =20

The peer learns the local domain name at the time of ERX bootstrapping
and uses that, along with the corresponding rIKName as the username part
of its NAI at the time of reauthentication. =20

Vidya

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Wed, 09 Jan 2008 15:44:16 +0000
From: "David B. Nelson" <[e-mail]>
To: <[e-mail]>
Subject: RE: Questions on modified Extended Attribute format?
Date: Wed, 9 Jan 2008 10:43:27 -0500
Message-ID: <004e01c852d6$61d61c40$011716ac@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AchSfy9slkyWKStwTW2l6JAtWhKJmAAVslhg

Avi Lior writes...

> An attribute can appear standalone and also be included in a group 
> (for that matter, in many groups).  The definition of the attribute 
> is the same in both cases, but the semantics is different right?

I'm confused by this.  The "definition" of the attribute consists of syntax
(format) and semantics (meaning).  What does it means to say that the
definition is the same but the semantics (meaning) is different?




--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Wed, 09 Jan 2008 14:40:08 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Questions on modified Extended Attribute format?
Date: Wed, 9 Jan 2008 09:39:17 -0500
Message-ID: <[e-mail]>
From: "Avi Lior" <[e-mail]>
To: "Bernard Aboba" <[e-mail]>, "David B. Nelson" <[e-mail]>, <[e-mail]>

Bernard,

Here is the WiMAX VSA definition (the payload of a RADIUS Type 26
attribute).  As you can see it aligns with the earlier proposal.  The
fragmentation concept is used but the tag concept is not used but is
reserved.=20

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WiMAX Type    | Length        | Continuation  | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


The Continuation Field is defined as follows:
 0
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|C|r|r|r|r|r|r|r|
+-+-+-+-+-+-+-+-+
The C-bit of the continuation field indicates if a WiMAX attribute is
being fragmented.
When the C-bit is set to one '1' this indicates that the attribute is
being fragmented that is
the next WiMAX VSA of the same WiMAX type is to be appended to this
attribute.
When the C-bit is set to zero '0' this indicates that the next attribute
is not a fragment of
this attribute.
A WiMAX attribute that is not being fragmented will have the C-bit set
to '0'. A WiMAX
attribute that is being fragmented will have its C-bit set to '1' for
all fragments until the last
fragment which will have its C-bit set to '0' indicating it's the last
fragment of the attribute.
The r-bits are reserved for future use. They SHALL be set to zero by the
sender and
SHALL be ignored by the receiver.
=20

> -----Original Message-----
> From: Bernard Aboba [mailto:[e-mail]]=20
> Sent: Wednesday, January 09, 2008 3:11 AM
> To: Avi Lior; David B. Nelson; [e-mail]
> Subject: RE: Questions on modified Extended Attribute format?
>=20
>=20
> Avi --
>=20
> Is it correct to say that the current proposal is compatible=20
> with WiMAX VSAs?=20
>=20
> For example, is there no tag part in the WiMAX VSAs, or is it=20
> just not used in any existing VSAs?=20
> ----------------------------------------
> > Subject: RE: Questions on modified Extended Attribute format?
> > Date: Tue, 8 Jan 2008 22:17:22 -0500
> > From: [e-mail]
> > To: [e-mail]; [e-mail]
> >=20
> > WiMAX did try to align at one time.  But things have changed.
> >=20
> > And to get WiMAX to align again with the IETF would be hard=20
> now.  We=20
> > would need a good reason to change given that we have=20
> implementation.
> > But not impossible since lots of things are changing.
> >=20
> > But to be 100 clear, the WiMAX encoding is WiMAX's encoding and not=20
> > IETF.  While compatiblity is desirable it is not required=20
> at this stage.
> >=20
> > It would have been nice if the IETF addressed the issues -- much --=20
> > earlier.
> >=20
> > Note in WiMAX we use the M bit but dont use the tag part.=20
> >=20
> >> -----Original Message-----
> >> From: [e-mail]
> >> [mailto:[e-mail]] On Behalf Of David B. Nelson
> >> Sent: Wednesday, December 26, 2007 9:59 PM
> >> To: [e-mail]
> >> Subject: RE: Questions on modified Extended Attribute format?
> >>=20
> >> Bernard Aboba writes...
> >> =20
> >>>>  WiMAX uses the same attribute format as proposed here.  Changes=20
> >>>> that are incompatible with WiMAX should be discouraged.
> >>>=20
> >>> I would agree.   If the extensions remain compatible with=20
> WiMAX then
> >>> the amount of code duplication will be minimized.
> >>=20
> >> I'm not so sure that I agree.  We should do what's right for the=20
> >> RADIUS community.  If that happens to be compatible with=20
> WiMAX, then=20
> >> great.
> >>=20
> >>=20
> >>=20
> >> --
> >> to unsubscribe send a message to
> >> [e-mail] with the word 'unsubscribe' in a=20
> >> single line as the message text body.
> >> archive:=20
> >>=20
> >=20
> > --
> > to unsubscribe send a message to=20
> [e-mail] with=20
> > the word 'unsubscribe' in a single line as the message text body.
> > archive:=20
>=20

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Wed, 09 Jan 2008 09:56:10 +0000
Message-ID: <[e-mail]>
Date: Wed, 09 Jan 2008 10:53:35 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: Hannes Tschofenig <[e-mail]>, [e-mail],  [e-mail], [e-mail]
Subject: Re: [HOKEY] a transparent proposal
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
>>   It is up to that domain to ensure all of it's AAA servers have the
>> same policy.  This includes managing state for multiple login detection,
>> and potentially re-auth keys.
> 
> Doesn't this imply a significant degree of complexity?  For example,
> one argument for the RFC 4507 PAC is that avoiding server-side state
> enables better scaling and authentication performance, because RADIUS
> servers don't replicate TLS key state.

  The re-authentication credentials aren't TLS key state, though.  From
the current proposals, they're just opaque keys.  They may be
*generated* from TLS key state, but once generated, they can be cached
by intermediate servers.

>  It's hard to reconcile that
> argument with the idea of having the domain keeping track of server side
> state. 

  Some server somewhere has to keep track of the re-authentication
credentials.

  Alan DeKok.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Wed, 09 Jan 2008 08:19:03 +0000
Message-ID: <[e-mail]>
From: Bernard Aboba <[e-mail]>
To: Alan DeKok <[e-mail]>
CC: Hannes Tschofenig <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: [HOKEY] a transparent proposal
Date: Wed, 9 Jan 2008 00:17:55 -0800
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

>   It is up to that domain to ensure all of it's AAA servers have the
> same policy.  This includes managing state for multiple login detection,
> and potentially re-auth keys.

Doesn't this imply a significant degree of complexity?  For example, one ar=
gument for the RFC 4507 PAC is that avoiding server-side state enables bett=
er scaling and authentication performance, because RADIUS servers don't rep=
licate TLS key state.  It's hard to reconcile that argument with the idea o=
f having the domain keeping track of server side state.=20

If there is a way to push that state on the peer, things would be much simp=
ler.  For example, if the ERX exchange were to leave the peer with an NAI i=
dentifying the "local server" and corresponding key state, then the peer co=
uld use that "re-auth" NAI in subsequent requests.=20

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Wed, 09 Jan 2008 08:11:25 +0000
Message-ID: <[e-mail]>
From: Bernard Aboba <[e-mail]>
To: Avi Lior <[e-mail]>, "David B. Nelson" <[e-mail]>, <[e-mail]>
Subject: RE: Questions on modified Extended Attribute format?
Date: Wed, 9 Jan 2008 00:11:00 -0800
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Avi --

Is it correct to say that the current proposal is compatible with WiMAX VSA=
s?=20

For example, is there no tag part in the WiMAX VSAs, or is it just not used=
 in any existing VSAs?=20
----------------------------------------
> Subject: RE: Questions on modified Extended Attribute format?
> Date: Tue, 8 Jan 2008 22:17:22 -0500
> From: [e-mail]
> To: [e-mail]; [e-mail]
>=20
> WiMAX did try to align at one time.  But things have changed.
>=20
> And to get WiMAX to align again with the IETF would be hard now.  We
> would need a good reason to change given that we have implementation.
> But not impossible since lots of things are changing.
>=20
> But to be 100 clear, the WiMAX encoding is WiMAX's encoding and not
> IETF.  While compatiblity is desirable it is not required at this stage.
>=20
> It would have been nice if the IETF addressed the issues -- much --
> earlier. =20
>=20
> Note in WiMAX we use the M bit but dont use the tag part.=20
>=20
>> -----Original Message-----
>> From: [e-mail]=20
>> [mailto:[e-mail]] On Behalf Of David B. Nelson
>> Sent: Wednesday, December 26, 2007 9:59 PM
>> To: [e-mail]
>> Subject: RE: Questions on modified Extended Attribute format?
>>=20
>> Bernard Aboba writes...
>> =20
>>>>  WiMAX uses the same attribute format as proposed here.  Changes=20
>>>> that are incompatible with WiMAX should be discouraged.
>>>=20
>>> I would agree.   If the extensions remain compatible with WiMAX then
>>> the amount of code duplication will be minimized.
>>=20
>> I'm not so sure that I agree.  We should do what's right for=20
>> the RADIUS community.  If that happens to be compatible with=20
>> WiMAX, then great.
>>=20
>>=20
>>=20
>> --
>> to unsubscribe send a message to=20
>> [e-mail] with the word 'unsubscribe' in=20
>> a single line as the message text body.
>> archive:=20
>>=20
>=20
> --
> to unsubscribe send a message to [e-mail] with
> the word 'unsubscribe' in a single line as the message text body.
> archive:=20

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Wed, 09 Jan 2008 07:29:00 +0000
Message-ID: <[e-mail]>
Date: Wed, 09 Jan 2008 08:26:52 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: Hannes Tschofenig <[e-mail]>, [e-mail],  [e-mail], [e-mail]
Subject: Re: [HOKEY] a transparent proposal
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> However, the routing requirements for the ERX application are different
> from those in normal AAA exchanges, because here key state (unlike the
> AAA credentials database) is not replicated.   That means that messages
> can't just be routed based on a "Domain Identifier" -- they actually
> have to be addressed to specific servers, since only those servers will
> hold the required key state.

  Yes and no.  The NAI could be decorated with a re-auth request, e.q.
"[e-mail]@REAUTH".  Existing servers not implementing re-auth
could be configured to strip/ignore "@REAUTH", and forward the request
as normal.

  Servers implementing re-auth could forward the request to a
re-authentication server.  The key data obtained on initial login could
also be forwarded to that same re-authentication server.  Nobody else
needs to know or care where those servers are located.

  Of course, this only works for re-authentication within one domain.
If the user tries to re-authenticate to a different domain, then the
request has to be forwarded back up the proxy chain to another server
which has cached those credentials, or which can authenticate the user
from scratch.

> For example, a "session resume NAI" could identify the specific EAP
> Session-Id that is being resumed, as well as the realm in which that key
> resides.  However, an NAI including only the realm will not necessarily
> be routed to the server or proxy that holds the key state, because AAA
> deployments often point the authenticators at different AAA servers or
> proxies for load balancing purposes.   To ensure that the request goes
> to the right place, the specific server name needs to be provided within
> the NAI. 

  It is up to that domain to ensure all of it's AAA servers have the
same policy.  This includes managing state for multiple login detection,
and potentially re-auth keys.

  Alan DeKok.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Wed, 09 Jan 2008 07:23:00 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Questions on modified Extended Attribute format?
Date: Tue, 8 Jan 2008 23:21:15 -0800
Message-ID: <[e-mail]>
Thread-Topic: Questions on modified Extended Attribute format?
Thread-Index: AchSbuRMMM3Ce/qKQP+07RROHM0WOwAIIl3A
From: "Matt Holdrege" <[e-mail]>
To: "Avi Lior" <[e-mail]>, "David B. Nelson" <[e-mail]>, <[e-mail]>

While I completely understand the disappointment with the IETF RADIUS
development process I don't think that it is a good idea to give up on
alignment. Alignment is a VERY serious issue given that mixed 802.11 and
802.16 networks will be the norm for many, many years to come.=20

And although there are a few WiMax implementations out now, 802.16e in a
real sense still hasn't started yet so I don't see any serious problem
with making changes.=20

-Matt


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Avi Lior
Sent: Wednesday, January 09, 2008 4:17 AM
To: David B. Nelson; [e-mail]
Subject: RE: Questions on modified Extended Attribute format?

WiMAX did try to align at one time.  But things have changed.

And to get WiMAX to align again with the IETF would be hard now.  We
would need a good reason to change given that we have implementation.
But not impossible since lots of things are changing.

But to be 100 clear, the WiMAX encoding is WiMAX's encoding and not
IETF.  While compatiblity is desirable it is not required at this stage.

It would have been nice if the IETF addressed the issues -- much --
earlier. =20

Note in WiMAX we use the M bit but dont use the tag part.=20

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of David B. Nelson
> Sent: Wednesday, December 26, 2007 9:59 PM
> To: [e-mail]
> Subject: RE: Questions on modified Extended Attribute format?
>=20
> Bernard Aboba writes...
> =20
> > >  WiMAX uses the same attribute format as proposed here.  Changes=20
> > > that are incompatible with WiMAX should be discouraged.
> >=20
> > I would agree.   If the extensions remain compatible with WiMAX then
> > the amount of code duplication will be minimized.
>=20
> I'm not so sure that I agree.  We should do what's right for=20
> the RADIUS community.  If that happens to be compatible with=20
> WiMAX, then great.
>=20
>=20
>=20
> --
> to unsubscribe send a message to=20
> [e-mail] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Wed, 09 Jan 2008 07:18:02 +0000
Message-ID: <[e-mail]>
Date: Wed, 09 Jan 2008 08:14:05 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Avi Lior <[e-mail]>
CC: "Romascanu, Dan (Dan)" <[e-mail]>,  Glen Zorn <[e-mail]>, [e-mail]
Subject: Re: Questions on modified Extended Attribute format?
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Avi Lior wrote:
> I dont understand Alan's comment.  The NAS-IP that appears in the RADIUS
> message is semantically different then the NAS-IP attribute that is
> going to be grouped.  The semantics for the former case is defined by
> RFC2865 and the semantics of the later case would be defined by a new
> RFC.

  The traditional RADIUS data model has involved defining new attributes
for new semantics, even if the contents are commonly understood items
like IP addresses.

> This is no different in Diameter.  An attribute can appear standalone
> and also be included in a group (for that matter, in many groups).  The
> definition of the attribute is the same in both cases, but the semantics
> is different right?

  Diameter implementations are more flexible and capable about AVP's
than RADIUS implementations.  This is solely because the Diameter AVP
format is more flexible and capable than the RADIUS AVP format.

  If we agree to use the Diameter format for extended attributes, then
we would obtain all of the benefits of that format for new attributes.
And that format is more flexible and capable than the current proposal
in the extended attributes draft.

  Alan DeKok.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Wed, 09 Jan 2008 05:15:58 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Questions on modified Extended Attribute format?
Date: Wed, 9 Jan 2008 00:15:12 -0500
Message-ID: <[e-mail]>
From: "Avi Lior" <[e-mail]>
To: "Romascanu, Dan (Dan)" <[e-mail]>, "Glen Zorn" <[e-mail]>, "Alan DeKok" <[e-mail]>
Cc: <[e-mail]>

Regarding allowing legacy attributes to be grouped within the extended
attribute.

Lets look at it from a practical perspective.  If I am writing a new
"Application" which will use grouping and I need to encode the IP
address of the NAS.

In Glen's proposal I would reuse the existing attribute NAS-IP vs. what
others are saying I would have to create a new attribute called
New-NAS-IP and include that in the grouped attribute.

Glen's approach *seems* more appropriate no?

I dont understand Alan's comment.  The NAS-IP that appears in the RADIUS
message is semantically different then the NAS-IP attribute that is
going to be grouped.  The semantics for the former case is defined by
RFC2865 and the semantics of the later case would be defined by a new
RFC.

This is no different in Diameter.  An attribute can appear standalone
and also be included in a group (for that matter, in many groups).  The
definition of the attribute is the same in both cases, but the semantics
is different right?

So what am I missing?

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Wed, 09 Jan 2008 03:18:54 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Questions on modified Extended Attribute format?
Date: Tue, 8 Jan 2008 22:17:22 -0500
Message-ID: <[e-mail]>
From: "Avi Lior" <[e-mail]>
To: "David B. Nelson" <[e-mail]>, <[e-mail]>

WiMAX did try to align at one time.  But things have changed.

And to get WiMAX to align again with the IETF would be hard now.  We
would need a good reason to change given that we have implementation.
But not impossible since lots of things are changing.

But to be 100 clear, the WiMAX encoding is WiMAX's encoding and not
IETF.  While compatiblity is desirable it is not required at this stage.

It would have been nice if the IETF addressed the issues -- much --
earlier. =20

Note in WiMAX we use the M bit but dont use the tag part.=20

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of David B. Nelson
> Sent: Wednesday, December 26, 2007 9:59 PM
> To: [e-mail]
> Subject: RE: Questions on modified Extended Attribute format?
>=20
> Bernard Aboba writes...
> =20
> > >  WiMAX uses the same attribute format as proposed here.  Changes=20
> > > that are incompatible with WiMAX should be discouraged.
> >=20
> > I would agree.   If the extensions remain compatible with WiMAX then
> > the amount of code duplication will be minimized.
>=20
> I'm not so sure that I agree.  We should do what's right for=20
> the RADIUS community.  If that happens to be compatible with=20
> WiMAX, then great.
>=20
>=20
>=20
> --
> to unsubscribe send a message to=20
> [e-mail] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Tue, 08 Jan 2008 17:13:28 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_4d73e889-c166-455e-8220-6afb77834fd1_"
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>
Subject: RE: Questions on modified Extended Attribute format?
Date: Tue, 8 Jan 2008 09:13:00 -0800
MIME-Version: 1.0

--_4d73e889-c166-455e-8220-6afb77834fd1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


>   We've been having this argument for too long.  We need to stop NOW,
> pick a format, and move on.  The endless re-visiting of attribute format
> is holding up other key work.

This discussion does need to stop. =20

The RADEXT WG has already discussed this issue extensively, and come to
consensus.  Re-design of the RADIUS attribute format (as originally advocat=
ed
in the "Design Guidelines" document) was discussed and rejected.
"Diameter in RADIUS" proposals were discussed and rejected.=20
The consensus of the WG has been to extend the RADIUS attribute format in
backward compatible manner, and that is a requirement in the RADEXT WG
charter.

Since other IETF documents have a dependency on attribute extension, we nee=
d to
get on with it.=20

Perhaps the quickest way to do that is to bring the document to WG last=20
call, and focus on addressing the last call comments from this point forwar=
d.



--_4d73e889-c166-455e-8220-6afb77834fd1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
&gt;   We've been having this argument for too long.  We need to stop NOW,<=
br>&gt; pick a format, and move on.  The endless re-visiting of attribute f=
ormat<br>&gt; is holding up other key work.<br><br>This discussion does nee=
d to stop.&nbsp; <br><br>The RADEXT WG has already discussed this issue ext=
ensively, and come to<br>consensus.&nbsp; Re-design of the RADIUS attribute=
 format (as originally advocated<br>in the "Design Guidelines" document) wa=
s discussed and rejected.<br>"Diameter in RADIUS" proposals were discussed =
and rejected. <br>The consensus of the WG has been to extend the RADIUS att=
ribute format in<br>backward compatible manner, and that is a requirement i=
n the RADEXT WG<br>charter.<br><br>Since other IETF documents have a depend=
ency on attribute extension, we need to<br>get on with it. <br><br>Perhaps =
the quickest way to do that is to bring the document to WG last <br>call, a=
nd focus on addressing the last call comments from this point forward.<br><=
br><br></body>
</html>=

--_4d73e889-c166-455e-8220-6afb77834fd1_--

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Tue, 08 Jan 2008 09:24:56 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Questions on modified Extended Attribute format?
Date: Tue, 8 Jan 2008 10:23:40 +0100
Message-ID: <[e-mail]>
Thread-Topic: Questions on modified Extended Attribute format?
Thread-Index: AchNvxvE95gozpjSQoKAVguApoAI+AAZAbTwAO0zArA=
From: "Romascanu, Dan (Dan)" <[e-mail]>
To: "Glen Zorn" <[e-mail]>, "Alan DeKok" <[e-mail]>
Cc: <[e-mail]>

=20
=20

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Glen Zorn
> Sent: Tuesday, January 08, 2008 8:45 AM
> To: 'Alan DeKok'
> Cc: [e-mail]
> Subject: RE: Questions on modified Extended Attribute format?
>=20
> Glen Zorn wrote:
>=20
> > As I said, put that way or any other way you like, ANY change is=20
> > incompatible with existing deployments.  If one were to add a new
> "standard"
> > attribute (in the old format or the proposed VSA-like format or any=20
> > other) it would be incompatible with existing deployments.
>=20
>   That isn't the point.  Everyone accepts that=20
> implementations have to be updated to handle new standards. =20
> One of the major efforts in RADIUS has been to maintain=20
> backwards compatibility with existing deployments.
> [gwz]
> You keep saying that but I really don't know where you get=20
> this funny idea.
> [/gwz]
>=20

The current RADEXT charter is quite explicit about the requirements for
backwards compatibility.=20

- All RADIUS work MUST be backward compatible with existing RADIUS=20
RFCs,
including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, and 3580.

Dan

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Tue, 08 Jan 2008 08:35:19 +0000
Message-ID: <[e-mail]>
Date: Tue, 08 Jan 2008 09:31:55 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Glen Zorn <[e-mail]>
CC: [e-mail]
Subject: Re: Questions on modified Extended Attribute format?
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:
> You keep saying that but I really don't know where you get this funny idea.

  New extensions cannot break existing deployments.

  This is NOT the same as saying new extensions require new code for
implementations to support those extensions.

>> [ re: packing standard attributes inside of extended ]
> Only if the authentication method in use is EAP, I think.  RFC 2865 doesn't
> list any attributes as required in any type of response; if your client
> fails because it can't find any attributes in the packet, your client is
> broken.

  The client will reject the user, or will apply the wrong policy (i.e.
default "empty response" policy, rather than the policy in the
response).  Please explain to the user and administrator that the users
are being rejected because of a new feature in RADIUS, and that this is
a Good Thing.

> Really?  Tell me what happens when a NAS receives, say, a tunnel attribute
> that it doesn't understand; then tell me how that is different from the
> introduction of _any_ new standard attribute and how it constitutes
> "communication".

  The issue is NOT introduction of a new standard attribute.  The issue
is encapsulating standard attributes that the client DOES understand in
a VSA that the client DOES NOT understand.

> Care to expand upon that a bit?

  If you're going to increase the attribute space, AND support long
attributes, you might as well give up and use the Diameter AVP format.
Your proposal involves:

   VSA header: 2 bytes  (type, length)
   Vendor-Id of zero: 4 bytes
   Extended attribute header: 3 bytes (16 bit type + length)
   "continuation" flag: 1 byte

  For a total of 10 bytes of header for one attribute.

  The "Diameter AVP in RADIUS" involves:

   new attribute header: 2 bytes
   Diamater header: 8 bytes (4 byte type + 4 byte length)

  For a total of 10 bytes.  Plus, conversion to Diameter in Diameter to
RADIUS gateways is easy.  We can get arbitrary grouping via the Diameter
method.  We can have attributes as long as we want.  AND the coding is
much, much, easier.

  I implemented the Diameter format as a test a while ago, and it was
~400 LoC, in part because it could leverage the existing code base of
Diameter encapsulation/decapsulation.  I've been looking at the extended
attribute format.  It doesn't leverage any existing code.  It has an
awkward "continuation" byte, which means it can't use any of the
pre-existing VSA handlers, etc.

  This proposal offers LESS than the "Diameter AVP in RADIUS" does, at
the cost of MORE work.

  We've been having this argument for too long.  We need to stop NOW,
pick a format, and move on.  The endless re-visiting of attribute format
is holding up other key work.

  Alan DeKok.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Tue, 08 Jan 2008 06:56:12 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Bernard Aboba'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Questions on modified Extended Attribute format?
Date: Mon, 7 Jan 2008 22:55:35 -0800
Message-ID: <004501c851c3$78f89a10$6ae9ce30$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0046_01C85180.6AD55A10"
Thread-Index: AchN5trgZzyCwneHS9W+QM1y+/JgmwCEtMHA
Content-Language: en-us

This is a multipart message in MIME format.

------=_NextPart_000_0046_01C85180.6AD55A10
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

> This proposal breaks that completely. It will be perfectly legal for
> implementations of your proposal to put ALL RADIUS attributes as
> grouped, inside of an "extended attribute". Any NAS that receives such
> a response will get a packet containing *nothing* but VSA's. It will
> then decide that there is nothing in the packet that it recognizes, and
> will fail.
>
> i.e. your proposal creates a new protocol that is incompatible with
> legacy RADIUS.
 
Presumbably new attributes using the extended format will define 
whether they can be grouped or not, and if so, what the grouping
means.  
 
But what about legacy attributes?  For example, what would it mean for a 
NAS-Identifier attribute to be grouped with say, a Tunnel-Password
attribute?   Presumably, this document would not define the semantics
of grouping for legacy attributes, which begs the question of where,
if anywhere, that semantic would be specified.  

[gwz]

 Presumably, the implementors would be interested in actually accomplishing
something & not merely playing word games & landing red herrings.  They also
might not ignore the second word in the phrase "group related attributes"
which occurs at least 6 times in the draft.  Are NAS-Identifier &
Tunnel-Password related attributes?  If so, and someone wanted to group them
together, that could be documented.

[/gwz]


 
Unless that semantic is specified somewhere (and I doubt it would be
specified anywhere for a substantial period of time), then the semantics
of grouping of legacy attributes is likely to be "implementation specific". 

[gwz]

Why is it necessary to specify the semantics of every possible combination
of RADIUS attributes?  Obviously, it's not; all that is required is to
define those groups that are useful, which in any reasonable process could
be done as the utility of those groupings became apparent.
 [/gwz]


So not only would the "new" RADIUS not be backward compatible with
the old one -- it wouldn't even have a public specification. 


------=_NextPart_000_0046_01C85180.6AD55A10
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>&gt;
This proposal breaks that completely. It will be perfectly legal for<br>
&gt; implementations of your proposal to put ALL RADIUS attributes =
as<br>
&gt; grouped, inside of an &quot;extended attribute&quot;. Any NAS that =
receives
such<br>
&gt; a response will get a packet containing *nothing* but VSA's. It =
will<br>
&gt; then decide that there is nothing in the packet that it recognizes, =
and<br>
&gt; will fail.<br>
&gt;<br>
&gt; i.e. your proposal creates a new protocol that is incompatible =
with<br>
&gt; legacy RADIUS.<br>
&nbsp;<br>
Presumbably new attributes using the extended format will define <br>
whether they can be grouped or not, and if so, what the grouping<br>
means.&nbsp; <br>
&nbsp;<br>
But what about legacy attributes?&nbsp; For example, what would it mean =
for a <br>
NAS-Identifier attribute to be grouped with say, a Tunnel-Password<br>
attribute?&nbsp;&nbsp; Presumably, this document would not define the =
semantics<br>
of grouping for legacy attributes, which begs the question of where,<br>
if anywhere, that semantic would be specified.&nbsp; <span =
style=3D'color:#1F497D'><o:p></o:p></span></span></p>

<p class=3DMsoNormal><b><i><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>[gwz]<o:p></o:p></span></i></b></p>

<p class=3DMsoNormal><b><i><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>&nbsp;Presumably, the implementors would be interested in
actually accomplishing something &amp; not merely playing word games =
&amp;
landing red herrings.&nbsp; They also might not ignore the second word =
in the phrase
&quot;group related attributes&quot; which occurs at least 6 times in =
the
draft.&nbsp; Are NAS-Identifier &amp; Tunnel-Password =
</span></i></b><b><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>related<i>
attributes?&nbsp; If so, and someone wanted to group them together, that =
could
be documented.<o:p></o:p></i></span></b></p>

<p class=3DMsoNormal><b><i><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>[/gwz]<o:p></o:p></span></i></b></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'><br>
&nbsp;<br>
Unless that semantic is specified somewhere (and I doubt it would be<br>
specified anywhere for a substantial period of time), then the =
semantics<br>
of grouping of legacy attributes is likely to be &quot;implementation
specific&quot;. <o:p></o:p></span></p>

<p class=3DMsoNormal><b><i><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>[gwz]<o:p></o:p></span></i></b></p>

<p class=3DMsoNormal><b><i><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Why is it necessary to specify the semantics of every =
possible
combination of RADIUS attributes?&nbsp; Obviously, it's not; all that is
required is to define those groups that are useful, which in any =
reasonable
process could be done as the utility of those groupings became =
apparent.<br>
&nbsp;[/gwz]<o:p></o:p></span></i></b></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'><br>
So not only would the &quot;new&quot; RADIUS not be backward compatible =
with<br>
the old one -- it wouldn't even have a public specification. =
<o:p></o:p></span></p>

</div>

</body>

</html>

------=_NextPart_000_0046_01C85180.6AD55A10--


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Tue, 08 Jan 2008 06:46:14 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Alan DeKok'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Questions on modified Extended Attribute format?
Date: Mon, 7 Jan 2008 22:44:53 -0800
Message-ID: <003e01c851c1$fad525f0$f07f71d0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: AchNvxvE95gozpjSQoKAVguApoAI+AAZAbTw
Content-Language: en-us

Glen Zorn wrote:

> As I said, put that way or any other way you like, ANY change is
> incompatible with existing deployments.  If one were to add a new
"standard"
> attribute (in the old format or the proposed VSA-like format or any other)
> it would be incompatible with existing deployments.

  That isn't the point.  Everyone accepts that implementations have to
be updated to handle new standards.  One of the major efforts in RADIUS
has been to maintain backwards compatibility with existing deployments.
[gwz] 
You keep saying that but I really don't know where you get this funny idea.
[/gwz]

  i.e. if a product doesn't implement the new standard, it can still
communicate with products that do implement that standard.
[gwz] 


  This proposal breaks that completely.  It will be perfectly legal for
implementations of your proposal to put ALL RADIUS attributes as
grouped, inside of an "extended attribute".  Any NAS that receives such
a response will get a packet containing *nothing* but VSA's.  It will
then decide that there is nothing in the packet that it recognizes, and
will fail.
[gwz] 
Only if the authentication method in use is EAP, I think.  RFC 2865 doesn't
list any attributes as required in any type of response; if your client
fails because it can't find any attributes in the packet, your client is
broken.  Of course, if the aim is to maintain backwards compatibility with
existing _deployments_ (rather than the existing _protocol_) we need to
support broken clients, right?
[/gwz]

  i.e. your proposal creates a new protocol that is incompatible with
legacy RADIUS.

[gwz]
Really?  Tell me what happens when a NAS receives, say, a tunnel attribute
that it doesn't understand; then tell me how that is different from the
introduction of _any_ new standard attribute and how it constitutes
"communication".
[/gwz]

> Actually, while the timeframe was long, the discussion wasn't: I've only
> received a couple of comments on it in the last months.  It _did_ take an
> inordinate amount of time to reject the 'Diameterization' of RADIUS,
> though...

  This proposal is no better.  It's worse in many respects.

[gwz]
Care to expand upon that a bit?
[/gwz]

  Alan DeKok.


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Tue, 08 Jan 2008 02:07:38 +0000
Message-ID: <[e-mail]>
Date: Mon, 7 Jan 2008 18:06:20 -0800 (PST)
Subject: a review of draft-gaonkar-radext-erp-attrs-02.txt
From: "Dan Harkins" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
User-Agent: SquirrelMail/1.4.8
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit

  Hello,

  I took a look at draft-gaonkar-radext-erp-attrs-02.txt and have
a few suggestions.

  First of all I suggest the Security Considerations be expanded
considerably. RFC4962 provides guidance to AAA key management protocols
and I would consider the key request/response from this draft to fall
into that category. This RFC lists mandatory requirements that acceptable
key management solutions MUST comply with and provides recommendations
that acceptable key management solutions SHOULD comply with. It is my
understanding that certain of these requirements and recommendations
cannot be supported by this draft and those should be explicitly spelled
out in the Security Considerations with text explaining why RFC4962 is
not being adhered to.

  For instance:

   - Prevent the Domino Effect
     The requirement is that compromise of a single entity (with the
     obvious exception of the root of a key hierarchy, e.g. the holder
     of the EMSK) will not affect keys held by other entities. This
     is not possible when proxies are involved.

     The RFC also states in the section on preventing the Domino Effect:
     "There are many implications of this requirement; however, two
     implications deserve highlighting.  First, the scope of the keying
     material must be defined and understood by all parties that
     communicate with a party that holds that keying material.  Second,
     a party that holds keying material in a key hierarchy must not share
     that keying material with parties that are associated with other
     branches in the key hierarchy."

     When proxies are involved I am not sure how the scope of the keying
     material can be defined and understood by all parties when knowledge
     of whether a proxy exists may not even be available to the other
     parties, for instance the peer. Also, when proxies are involved how
     are they going to be bypassed such that knowledge of multiple branches
     of a single key hierarchy will not be provided to a given proxy? I
     don't believe it's possible and the draft must address this.

   - Bind Key to Its Context
     The context bound to a key MUST include: "[t]he other parties that
     are expected to have access to the keying material." It is not clear
     how this can be adhered to when proxies are involved.

     It goes on to state: "In addition, the protocol MUST ensure that all
     parties with legitimate access to keying material have the same
     context for the keying material.  This requires that the parties are
     properly identified and authenticated, so that all of the parties
     that have access to the keying material can be determined." Again,
     it is not clear from the draft how all proxies (or even the existance
     of a single proxy) can be determined such that they can be identified.
     If it is not possible then the draft has to explain this.

  The Security Considerations has to explain the implications of sharing
keys like this, how proxies affect the security of a system implementing
this draft, and why mandatory requirements of an applicable RFC are not
being followed.

  My second suggestion is that the "key name" field be made variable.
Based on reading of related drafts it is apparent that SHA-256 is being
used to generate a unique string based on some key label and other cruft
and that output is being truncated to 8 bytes, hence the field is 8 bytes.
(The motivation for using such a strong mixing function only to throw
away most of the result should be mentioned _somewhere_!) But as long as
189 other possible key names it seems shortsighted to believe that everyone
else will generate 8 byte key names. For instance, RADEXT is considering
a keywrap draft that allots 20 bytes to key names. 802.11r is generating
key names that are 16 bytes. I'm not saying that this draft will be used
to request 802.11r keys but merely pointing out that there is no standard
size for a "key name" and it would be prudent to not fix one here,
especially one that is on the small end of the scale.

  My last comment concerns IPsec. A RADIUS client and RADIUS server cannot
know whether the data they send down to the IP layer is going to end up
being protected or not. I think that if a key is being sent by some
entity then that entity has to ensure it is being protected adequately
and to know that the entity has to protect the key itself. Either (D)TLS
should be specified or a key-wrapping scheme, preferably based on the SIV
mode of AES, be specified. Please do not mandate the use of IPsec with
RADIUS.

  regards,

  Dan.




--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Mon, 07 Jan 2008 23:31:38 +0000
DomainKey-Signature: s=qcdkim; d=qualcomm.com; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:Received:Received: X-MimeOLE:Content-class:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:Date:Message-ID: In-Reply-To:X-MS-Has-Attach:X-MS-TNEF-Correlator: Thread-Topic:Thread-Index:References:From:To:Cc: X-OriginalArrivalTime; b=e8HJLA0uek3K3jaYeecsXQBL5VGCMLERUmx7puBtBxy5pWi9kbLjO6HE Qh9/O5uPS3hNE4fWBZT3fLt5GXRifwQrDETKbLWSMjVS+aQ/RwqFgTsrq DxNZmdkXb4XxwidfN2SzG/z81r7/UqePqYoCg5BLbNqWvhApD8DfvlkEO w=;
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [HOKEY] a transparent proposal
Date: Mon, 7 Jan 2008 15:30:26 -0800
Message-ID: <[e-mail]>
Thread-Topic: [HOKEY] a transparent proposal
Thread-Index: AchRgdy2fZS/I5GFSD6EuKD8ye8sNwAAZUvw
From: "Narayanan, Vidya" <[e-mail]>
To: "Barney Wolff" <[e-mail]>, "Hannes Tschofenig" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>

Hi Barney, all,
An approach with unmodified authenticators was already considered and
rejected by the working group soon after its first meeting as a WG.
That was one of the very first points that was debated and the choice of
a single roundtrip protocol was made consciously, given that several
methods can already offer method-specific reauthentication in 2.5
roundtrips, which is the best the protocol can do with unmodified
authenticators. =20

These discussions can be found by digging through the archives and also
in the meeting minutes of the interim meeting from last year.  At this
stage, I'd like to see us make forward progress rather than revisit
topics that have been debated and put to rest a long time ago.=20

Regards,
Vidya=20

> -----Original Message-----
> From: Barney Wolff [mailto:[e-mail]]=20
> Sent: Monday, January 07, 2008 3:05 PM
> To: Hannes Tschofenig
> Cc: [e-mail]; [e-mail]
> Subject: Re: [HOKEY] a transparent proposal
>=20
> On Mon, Jan 07, 2008 at 10:54:02AM +0200, Hannes Tschofenig wrote:
> > I don't think that this works since the Authenticator needs=20
> to route=20
> > the messages to a local proxy that later acts as the local=20
> ER server.=20
> > Hence, the Authenticator needs to perform special routing=20
> > functionality. In my recent mail to the list I was=20
> wondering whether=20
> > in Diameter one would have to define a new Diameter application for=20
> > EAP-ER to accomplish this routing since otherwise you might=20
> encounter other interesting effects.
>=20
> It does work, if the NAI that the peer supplies routes=20
> "naturally" to a local ER server.  There is no reason the=20
> peer cannot accomplish this, as it certainly knows that it is=20
> attempting reauth.  Any NAI that ends in .reauth or @reauth=20
> would be guaranteed to be workable, but we might consider=20
> whether something like ReAuTh%<iKeyname>%<seq>%<hash>%<originalNAI>
> might be better, as a reauth-supporting AAA proxy on the=20
> route could recognize it, while if there is no support for=20
> reauth in the new domain the request should end up at the=20
> original home AAA server.
>=20
> I'm a little vague on how the current HOKEY drafts are=20
> supposed to work in scenarios such as:
> -	new authenticator does not support reauth
> -	new authenticator supports reauth but the ER server=20
> failed to get the
> 	necessary info for this peer
>=20
> Any HOKEY scheme clearly has to be workable during what's=20
> likely to be an extended transition, in the sense that an=20
> upgraded peer should not cause an appreciably worse user=20
> experience than an old peer, when dealing with a non-upgraded=20
> domain, and vice-versa.  Or am I confused as to the intended=20
> deployment plans?
>=20
> Regards,
> Barney
>=20
> > Barney Wolff wrote:
> >> I've been reading the HOKEY drafts, and am somewhat taken aback by=20
> >> the extent of the required changes.  I know it's late in=20
> the process,=20
> >> but I wonder if the HOKEY group has considered and=20
> rejected an idea=20
> >> like the following.  If so, why?  If not, and there is some=20
> >> expression of support, I could write it up as a draft.
> >>=20
> >> Make HOKEY transparent to the authenticator - peer and=20
> server have to=20
> >> know, but the authenticator does not.
> >>=20
> >> As part of the initial EAP conversation, peer & server agree that=20
> >> HOKEY may be done.  The MSK that the server sends to the=20
> >> authenticator is not the real MSK, but a=20
> >> domain-authenticator-specific key derived from it that the=20
> peer can also derive.
> >>=20
> >> When the peer connects to another authenticator, the identity it=20
> >> supplies is a reauth-NAI given to it by the original server rather=20
> >> than the id it supplied at initial auth.  Based on the id, the new=20
> >> authenticator naturally routes its access-requests to a reauth=20
> >> server, without needing any code updates.  The reauth server goes=20
> >> through an abbreviated conversation with the peer, and=20
> upon success=20
> >> sends the newly-derived domain-authenticator-specific key to the=20
> >> authenticator.  Class can be used to tie together all the pieces.
> >>=20
> >> Advantages:
> >>=20
> >> Authenticator is completely unchanged.
> >>=20
> >> AAA proxies are completely unchanged.
> >>=20
> >> Peer behavior remains that of an EAP responder, rather than being=20
> >> both requester (for reauth) and responder (for initial=20
> auth) in the=20
> >> current HOKEY drafts.  The HOKEY drafts seem to do considerable=20
> >> philosophical violence to EAP in this regard.
> >>=20
> >> No new EAP codes.  HOKEY can be done as a new EAP method.
> >>=20
> >> Disadvantages:
> >>=20
> >> There is an extra round-trip, but it is to a (presumably local)=20
> >> reauth server.  Even that could be avoided if the=20
> authenticator were=20
> >> to be upgraded to recognize a reauth-identity and generate a=20
> >> reauth-eap request itself.  But I suspect that's not=20
> really necessary.
> >>=20
> >>  =20
>=20
> --=20
> Barney Wolff         I never met a computer I didn't like.
>=20
>=20
> _______________________________________________
> HOKEY mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/hokey
>=20

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Mon, 07 Jan 2008 23:06:09 +0000
Date: Mon, 7 Jan 2008 18:05:16 -0500
From: Barney Wolff <[e-mail]>
To: Hannes Tschofenig <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: [HOKEY] a transparent proposal
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.17 (2007-11-01)

On Mon, Jan 07, 2008 at 10:54:02AM +0200, Hannes Tschofenig wrote:
> I don't think that this works since the Authenticator needs to route the 
> messages to a local proxy that later acts as the local ER server. Hence, 
> the Authenticator needs to perform special routing functionality. In my 
> recent mail to the list I was wondering whether in Diameter one would have 
> to define a new Diameter application for EAP-ER to accomplish this routing 
> since otherwise you might encounter other interesting effects.

It does work, if the NAI that the peer supplies routes "naturally" to a
local ER server.  There is no reason the peer cannot accomplish this, as
it certainly knows that it is attempting reauth.  Any NAI that ends in
.reauth or @reauth would be guaranteed to be workable, but we might
consider whether something like ReAuTh%<iKeyname>%<seq>%<hash>%<originalNAI>
might be better, as a reauth-supporting AAA proxy on the route could
recognize it, while if there is no support for reauth in the new domain
the request should end up at the original home AAA server.

I'm a little vague on how the current HOKEY drafts are supposed to work
in scenarios such as:
-	new authenticator does not support reauth
-	new authenticator supports reauth but the ER server failed to get the
	necessary info for this peer

Any HOKEY scheme clearly has to be workable during what's likely to be an
extended transition, in the sense that an upgraded peer should not cause
an appreciably worse user experience than an old peer, when dealing with
a non-upgraded domain, and vice-versa.  Or am I confused as to the intended
deployment plans?

Regards,
Barney

> Barney Wolff wrote:
>> I've been reading the HOKEY drafts, and am somewhat taken aback by
>> the extent of the required changes.  I know it's late in the process,
>> but I wonder if the HOKEY group has considered and rejected an idea
>> like the following.  If so, why?  If not, and there is some expression
>> of support, I could write it up as a draft.
>> 
>> Make HOKEY transparent to the authenticator - peer and server have to know,
>> but the authenticator does not.
>> 
>> As part of the initial EAP conversation, peer & server agree that HOKEY may
>> be done.  The MSK that the server sends to the authenticator is not the
>> real MSK, but a domain-authenticator-specific key derived from it that
>> the peer can also derive.
>> 
>> When the peer connects to another authenticator, the identity it
>> supplies is a reauth-NAI given to it by the original server rather
>> than the id it supplied at initial auth.  Based on the id, the new
>> authenticator naturally routes its access-requests to a reauth
>> server, without needing any code updates.  The reauth server goes
>> through an abbreviated conversation with the peer, and upon success
>> sends the newly-derived domain-authenticator-specific key to the
>> authenticator.  Class can be used to tie together all the pieces.
>> 
>> Advantages:
>> 
>> Authenticator is completely unchanged.
>> 
>> AAA proxies are completely unchanged.
>> 
>> Peer behavior remains that of an EAP responder, rather than being both
>> requester (for reauth) and responder (for initial auth) in the current
>> HOKEY drafts.  The HOKEY drafts seem to do considerable philosophical
>> violence to EAP in this regard.
>> 
>> No new EAP codes.  HOKEY can be done as a new EAP method.
>> 
>> Disadvantages:
>> 
>> There is an extra round-trip, but it is to a (presumably local) reauth
>> server.  Even that could be avoided if the authenticator were to be
>> upgraded to recognize a reauth-identity and generate a reauth-eap
>> request itself.  But I suspect that's not really necessary.
>> 
>>   

-- 
Barney Wolff         I never met a computer I didn't like.


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Mon, 07 Jan 2008 19:01:05 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Barney Wolff'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: [HOKEY] a transparent proposal
Date: Mon, 7 Jan 2008 10:59:56 -0800
Message-ID: <008001c8515f$7fd11150$7f7333f0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AchQvQ70pYE6vRQFQlKy/mU1hEdJZAAoSy/w
Content-Language: en-us

I've been reading the HOKEY drafts, and am somewhat taken aback by
the extent of the required changes.  I know it's late in the process,
but I wonder if the HOKEY group has considered and rejected an idea
like the following.  If so, why?  If not, and there is some expression
of support, I could write it up as a draft.

[gwz] 
I think that this is a splendid idea, w/just one (major) problem: our
charter says that hokey must require 
"No changes to EAP methods.  Any extensions defined to EAP must not cause
changes to existing EAP methods."  In addition, hokey must not rely upon the
use of any particular (initial) EAP method, which is what it sounds like you
are suggesting.  If we could figure out how to pass back the reuth ID in
another way (maybe a Notification-Request injected into the initial EAP
conversation by the local hokey server?), I think this would be great.
[/gwz]

Make HOKEY transparent to the authenticator - peer and server have to know,
but the authenticator does not.

As part of the initial EAP conversation, peer & server agree that HOKEY may
be done.  The MSK that the server sends to the authenticator is not the
real MSK, but a domain-authenticator-specific key derived from it that
the peer can also derive.

When the peer connects to another authenticator, the identity it
supplies is a reauth-NAI given to it by the original server rather
than the id it supplied at initial auth.  Based on the id, the new
authenticator naturally routes its access-requests to a reauth
server, without needing any code updates.  The reauth server goes
through an abbreviated conversation with the peer, and upon success
sends the newly-derived domain-authenticator-specific key to the
authenticator.  Class can be used to tie together all the pieces.

Advantages:

Authenticator is completely unchanged.

AAA proxies are completely unchanged.

Peer behavior remains that of an EAP responder, rather than being both
requester (for reauth) and responder (for initial auth) in the current
HOKEY drafts.  The HOKEY drafts seem to do considerable philosophical
violence to EAP in this regard.

No new EAP codes.  HOKEY can be done as a new EAP method.

Disadvantages:

There is an extra round-trip, but it is to a (presumably local) reauth
server.  Even that could be avoided if the authenticator were to be
upgraded to recognize a reauth-identity and generate a reauth-eap
request itself.  But I suspect that's not really necessary.

-- 
Barney Wolff         I never met a computer I didn't like.


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Mon, 07 Jan 2008 18:57:40 +0000
DomainKey-Signature: s=qcdkim; d=qualcomm.com; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:Received:Received: X-MimeOLE:Content-class:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:Date:Message-ID: In-Reply-To:X-MS-Has-Attach:X-MS-TNEF-Correlator: Thread-Topic:Thread-Index:References:From:To:Cc: X-OriginalArrivalTime; b=GFkrzRceinJOeM5AMCkH5L01YcEVxGAZMcca4eC4lohiIDPPwrC7WVpQ PvwpaaLjA7pFkLrejNif1KC6fCIUJ8U55HWb/ZP1625jfB1BAyXCjclNX T5iRaYlz9qDsaUkz/fmnr+AZyPJHeHcG4+fc4CPJkpdNutMJNnl1om6wr Q=;
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: AAA Routing in ERX (was RE: [HOKEY] a transparent proposal)
Date: Mon, 7 Jan 2008 10:53:06 -0800
Message-ID: <[e-mail]>
Thread-Topic: AAA Routing in ERX (was RE: [HOKEY] a transparent proposal)
Thread-Index: AchRRh1pz5hF/7MgRhOGQUjRBX2TLwAFrGwg
From: "Narayanan, Vidya" <[e-mail]>
To: "Bernard Aboba" <[e-mail]>, "Hannes Tschofenig" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>

Hi Bernard,
AAA routing in ERX is still done based on the realm.  It is up to the
local domain how the key state replication is handled.  If there are
multiple local ER servers in the same domain for redundancy sake, key
state may be replicated across those servers.  While ERX provides no
provisions for such AAA replication, this is not restricted by ERX.=20

So, there are no changes to AAA routing between regular EAP and ERX.  In
fact, this was one of the debated points earlier on in the design when
the choice was made to keep the AAA routing the same to minimize impact
to AAA entities.=20

Thanks,
Vidya

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Bernard Aboba
> Sent: Monday, January 07, 2008 7:56 AM
> To: Hannes Tschofenig; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE: [HOKEY] a transparent proposal
>=20
> To avoid changes to existing RADIUS routing procedures, the=20
> messages would need to be routed to based on the realm in the NAI. =20
>=20
> However, the routing requirements for the ERX application are=20
> different from those in normal AAA exchanges, because here=20
> key state (unlike the AAA credentials database) is not=20
> replicated.   That means that messages can't just be routed=20
> based on a "Domain Identifier" -- they actually have to be=20
> addressed to specific servers, since only those servers will=20
> hold the required key state.=20
>=20
> For example, a "session resume NAI" could identify the=20
> specific EAP Session-Id that is being resumed, as well as the=20
> realm in which that key resides.  However, an NAI including=20
> only the realm will not necessarily be routed to the server=20
> or proxy that holds the key state, because AAA deployments=20
> often point the authenticators at different AAA servers or=20
> proxies for load balancing purposes.   To ensure that the=20
> request goes to the right place, the specific server name=20
> needs to be provided within the NAI. =20
>=20
> This may not be that easy to produce.  Not all EAP methods=20
> produce the Server-Id, so the peer may not be able to include=20
> the specific server name in a "session resume NAI" sent to=20
> the home AAA server.  For the peer to compose a "session=20
> resume NAI" for the local realm, it would have to learn the=20
> local server name, not just a "Domain Identifier". =20
>=20
>=20
> > Date: Mon, 7 Jan 2008 10:54:02 +0200
> > From: [e-mail]
> > To: [e-mail]
> > CC: [e-mail]; [e-mail]
> > Subject: Re: [HOKEY] a transparent proposal
> >=20
> > I don't think that this works since the Authenticator needs=20
> to route=20
> > the messages to a local proxy that later acts as the local=20
> ER server.=20
> > Hence, the Authenticator needs to perform special routing=20
> > functionality. In my recent mail to the list I was=20
> wondering whether=20
> > in Diameter one would have to define a new Diameter application for=20
> > EAP-ER to accomplish this routing since otherwise you might=20
> encounter other interesting effects.
> >=20
> > Ciao
> > Hannes
> >=20
> >=20
> >=20
> >=20
> >=20
> > Barney Wolff wrote:
> > > I've been reading the HOKEY drafts, and am somewhat taken=20
> aback by=20
> > > the extent of the required changes. I know it's late in=20
> the process,=20
> > > but I wonder if the HOKEY group has considered and=20
> rejected an idea=20
> > > like the following. If so, why? If not, and there is some=20
> expression=20
> > > of support, I could write it up as a draft.
> > >
> > > Make HOKEY transparent to the authenticator - peer and=20
> server have=20
> > > to know, but the authenticator does not.
> > >
> > > As part of the initial EAP conversation, peer & server agree that=20
> > > HOKEY may be done. The MSK that the server sends to the=20
> > > authenticator is not the real MSK, but a=20
> > > domain-authenticator-specific key derived from it that=20
> the peer can also derive.
> > >
> > > When the peer connects to another authenticator, the identity it=20
> > > supplies is a reauth-NAI given to it by the original=20
> server rather=20
> > > than the id it supplied at initial auth. Based on the id, the new=20
> > > authenticator naturally routes its access-requests to a reauth=20
> > > server, without needing any code updates. The reauth server goes=20
> > > through an abbreviated conversation with the peer, and=20
> upon success=20
> > > sends the newly-derived domain-authenticator-specific key to the=20
> > > authenticator. Class can be used to tie together all the pieces.
> > >
> > > Advantages:
> > >
> > > Authenticator is completely unchanged.
> > >
> > > AAA proxies are completely unchanged.
> > >
> > > Peer behavior remains that of an EAP responder, rather than being=20
> > > both requester (for reauth) and responder (for initial=20
> auth) in the=20
> > > current HOKEY drafts. The HOKEY drafts seem to do considerable=20
> > > philosophical violence to EAP in this regard.
> > >
> > > No new EAP codes. HOKEY can be done as a new EAP method.
> > >
> > > Disadvantages:
> > >
> > > There is an extra round-trip, but it is to a (presumably local)=20
> > > reauth server. Even that could be avoided if the=20
> authenticator were=20
> > > to be upgraded to recognize a reauth-identity and generate a=20
> > > reauth-eap request itself. But I suspect that's not=20
> really necessary.
> > >
> > >=20
> >=20
> >=20
> > --
> > to unsubscribe send a message to=20
> [e-mail] with=20
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
>=20
>=20

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Mon, 07 Jan 2008 18:51:43 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Bernard Aboba'" <[e-mail]>, "'Hannes Tschofenig'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: [HOKEY] a transparent proposal
Date: Mon, 7 Jan 2008 10:50:39 -0800
Message-ID: <007501c8515e$333c1390$99b43ab0$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0076_01C8511B.2518D390"
Thread-Index: AchRRn77XX9NdLvrSnqpprQryHHUQQAEXGBw
Content-Language: en-us

This is a multipart message in MIME format.

------=_NextPart_000_0076_01C8511B.2518D390
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

To avoid changes to existing RADIUS routing procedures, the messages would
need to be routed to based on the realm in the NAI.  
[gwz] Yes. [/gwz]
However, the routing requirements for the ERX application are different from
those in normal AAA exchanges, because here key state (unlike the AAA
credentials database) is not replicated.   

[gwz]

 I'm not sure where you get that idea; replication has not been called out
as a specific hokey requirement but I don't recall anyone saying that it
can't exist.

[/gwz]

That means that messages can't just be routed based on a "Domain Identifier"
-- they actually have to be addressed to specific servers, since only those
servers will hold the required key state. 

For example, a "session resume NAI" could identify the specific EAP
Session-Id that is being resumed, as well as the realm in which that key
resides.  However, an NAI including only the realm will not necessarily be
routed to the server or proxy that holds the key state, because AAA
deployments often point the authenticators at different AAA servers or
proxies for load balancing purposes.   To ensure that the request goes to
the right place, the specific server name needs to be provided within the
NAI.  

[gwz] 

Although it would be best if the sets of hokey and AAA  servers in a given
domain were to  intersect, it is not mandatory; in particvlar, the  sets
need not be not be equal.  This suggests that AAA  routing is essentially
irrelevant to hokey: it is the AAA routing method we're talking abour using,
not necessarily the AAA routes or infrastructure.  Even assuming that the
sets are equal, I'm not sure why the reauth state wouldn't be replicated the
with the rest of session state that is held by virtually all AAA (even
RADIUS) servers.

[/gwz] 

This may not be that easy to produce.  Not all EAP methods produce the
Server-Id, so the peer may not be able to include the specific server name
in a "session resume NAI" sent to the home AAA server.  For the peer to
compose a "session resume NAI" for the local realm, it would have to learn
the local server name, not just a "Domain Identifier".  

[gwz]

 OK, I also don't know why the peer would be composing this NAI; I thought
that the idea was that the reauth identity would be passed back to the peer
from the local reauth server as part of the original EAP conversation (maybe
in a Notification-Request, since we can't make hokey depend upon a "special"
initial EAP method).

[/gwz]


.


------=_NextPart_000_0076_01C8511B.2518D390
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>To
avoid changes to existing RADIUS routing procedures, the messages would =
need to
be routed to based on the realm in the NAI.&nbsp; <br>
</span><b><i><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>[gwz] Yes. [/gwz]</span></i></b><span =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif"'><br>
However, the routing requirements for the ERX application are different =
from
those in normal AAA exchanges, because here key state (unlike the AAA
credentials database) is not replicated.&nbsp;&nbsp; <span =
style=3D'color:#1F497D'><o:p></o:p></span></span></p>

<p class=3DMsoNormal><b><i><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>[gwz]<o:p></o:p></span></i></b></p>

<p class=3DMsoNormal><b><i><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>&nbsp;I'm not sure where you get that idea; replication =
has not
been called out as a specific hokey requirement but I don't recall =
anyone
saying that it can't exist.<o:p></o:p></span></i></b></p>

<p class=3DMsoNormal><b><i><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>[/gwz]<o:p></o:p></span></i></b></p>

<p class=3DMsoNormal><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>That
means that messages can't just be routed based on a &quot;Domain
Identifier&quot; -- they actually have to be addressed to specific =
servers,
since only those servers will hold the required key state. <br>
<br>
For example, a &quot;session resume NAI&quot; could identify the =
specific EAP
Session-Id that is being resumed, as well as the realm in which that key
resides.&nbsp; However, an NAI including only the realm will not =
necessarily be
routed to the server or proxy that holds the key state, because AAA =
deployments
often point the authenticators at different AAA servers or proxies for =
load
balancing purposes.&nbsp;&nbsp; To ensure that the request goes to the =
right
place, the specific server name needs to be provided within the =
NAI.&nbsp; <span
style=3D'color:#1F497D'><o:p></o:p></span></span></p>

<p class=3DMsoNormal><b><i><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>[gwz] <o:p></o:p></span></i></b></p>

<p class=3DMsoNormal><b><i><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Although it would be best if the sets of hokey and AAA =
&nbsp;servers
in a given domain were to &nbsp;intersect, it is not mandatory; in =
particvlar, the
&nbsp;sets need not be not be equal.&nbsp; This suggests that AAA =
&nbsp;routing
is essentially irrelevant to hokey: it is the AAA routing =
</span></i></b><b><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497=
D'>method
<i>we're talking abour using, not necessarily the AAA routes or =
infrastructure.&nbsp;
Even assuming that the sets are equal, I'm not sure why the reauth state
wouldn't be replicated the &nbsp;with the rest of session state that is =
held by
virtually all AAA (even RADIUS) servers.<o:p></o:p></i></span></b></p>

<p class=3DMsoNormal><b><i><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:#1F497D'>[/gwz] </span></i></b><span =
style=3D'font-size:10.0pt;font-family:
"Tahoma","sans-serif"'><br>
<br>
This may not be that easy to produce.&nbsp; Not all EAP methods produce =
the
Server-Id, so the peer may not be able to include the specific server =
name in a
&quot;session resume NAI&quot; sent to the home AAA server.&nbsp; For =
the peer
to compose a &quot;session resume NAI&quot; for the local realm, it =
would have
to learn the local server name, not just a &quot;Domain =
Identifier&quot;.&nbsp;
<span style=3D'color:#1F497D'><o:p></o:p></span></span></p>

<p class=3DMsoNormal><b><i><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>[gwz]<o:p></o:p></span></i></b></p>

<p class=3DMsoNormal><b><i><span =
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>&nbsp;OK, I also don't know why the peer would be =
composing this
NAI; I thought that the idea was that the reauth identity would be =
passed back
to the peer from the local reauth server as part of the original EAP
conversation (maybe in a Notification-Request, since we can't make hokey =
depend
upon a &quot;special&quot; initial EAP =
method).<o:p></o:p></span></i></b></p>

<p class=3DMsoNormal><b><i><span =
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";
color:#1F497D'>[/gwz]</span></i></b><span =
style=3D'font-size:10.0pt;font-family:
"Tahoma","sans-serif"'><br>
<br>
<br>
<span style=3D'color:#1F497D'>&#8230;</span><o:p></o:p></span></p>

</div>

</body>

</html>

------=_NextPart_000_0076_01C8511B.2518D390--


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Mon, 07 Jan 2008 15:57:10 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_534e0f42-8ceb-4f7d-b8fc-59108b4dfbac_"
From: Bernard Aboba <[e-mail]>
To: Hannes Tschofenig <[e-mail]>, <[e-mail]>
CC: <[e-mail]>, <[e-mail]>
Subject: RE: [HOKEY] a transparent proposal
Date: Mon, 7 Jan 2008 07:55:51 -0800
MIME-Version: 1.0

--_534e0f42-8ceb-4f7d-b8fc-59108b4dfbac_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


To avoid changes to existing RADIUS routing procedures, the messages would =
need to be routed to based on the realm in the NAI. =20

However, the routing requirements for the ERX application are different fro=
m those in normal AAA exchanges, because here key state (unlike the AAA cre=
dentials database) is not replicated.   That means that messages can't just=
 be routed based on a "Domain Identifier" -- they actually have to be addre=
ssed to specific servers, since only those servers will hold the required k=
ey state.=20

For example, a "session resume NAI" could identify the specific EAP Session=
-Id that is being resumed, as well as the realm in which that key resides. =
 However, an NAI including only the realm will not necessarily be routed to=
 the server or proxy that holds the key state, because AAA deployments ofte=
n point the authenticators at different AAA servers or proxies for load bal=
ancing purposes.   To ensure that the request goes to the right place, the =
specific server name needs to be provided within the NAI. =20

This may not be that easy to produce.  Not all EAP methods produce the Serv=
er-Id, so the peer may not be able to include the specific server name in a=
 "session resume NAI" sent to the home AAA server.  For the peer to compose=
 a "session resume NAI" for the local realm, it would have to learn the loc=
al server name, not just a "Domain Identifier". =20


> Date: Mon, 7 Jan 2008 10:54:02 +0200
> From: [e-mail]
> To: [e-mail]
> CC: [e-mail]; [e-mail]
> Subject: Re: [HOKEY] a transparent proposal
>=20
> I don't think that this works since the Authenticator needs to route the=
=20
> messages to a local proxy that later acts as the local ER server. Hence,=
=20
> the Authenticator needs to perform special routing functionality. In my=20
> recent mail to the list I was wondering whether in Diameter one would=20
> have to define a new Diameter application for EAP-ER to accomplish this=20
> routing since otherwise you might encounter other interesting effects.
>=20
> Ciao
> Hannes
>=20
>=20
>=20
>=20
>=20
> Barney Wolff wrote:
> > I've been reading the HOKEY drafts, and am somewhat taken aback by
> > the extent of the required changes.  I know it's late in the process,
> > but I wonder if the HOKEY group has considered and rejected an idea
> > like the following.  If so, why?  If not, and there is some expression
> > of support, I could write it up as a draft.
> >
> > Make HOKEY transparent to the authenticator - peer and server have to k=
now,
> > but the authenticator does not.
> >
> > As part of the initial EAP conversation, peer & server agree that HOKEY=
 may
> > be done.  The MSK that the server sends to the authenticator is not the
> > real MSK, but a domain-authenticator-specific key derived from it that
> > the peer can also derive.
> >
> > When the peer connects to another authenticator, the identity it
> > supplies is a reauth-NAI given to it by the original server rather
> > than the id it supplied at initial auth.  Based on the id, the new
> > authenticator naturally routes its access-requests to a reauth
> > server, without needing any code updates.  The reauth server goes
> > through an abbreviated conversation with the peer, and upon success
> > sends the newly-derived domain-authenticator-specific key to the
> > authenticator.  Class can be used to tie together all the pieces.
> >
> > Advantages:
> >
> > Authenticator is completely unchanged.
> >
> > AAA proxies are completely unchanged.
> >
> > Peer behavior remains that of an EAP responder, rather than being both
> > requester (for reauth) and responder (for initial auth) in the current
> > HOKEY drafts.  The HOKEY drafts seem to do considerable philosophical
> > violence to EAP in this regard.
> >
> > No new EAP codes.  HOKEY can be done as a new EAP method.
> >
> > Disadvantages:
> >
> > There is an extra round-trip, but it is to a (presumably local) reauth
> > server.  Even that could be avoided if the authenticator were to be
> > upgraded to recognize a reauth-identity and generate a reauth-eap
> > request itself.  But I suspect that's not really necessary.
> >
> >  =20
>=20
>=20
> --
> to unsubscribe send a message to [e-mail] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

--_534e0f42-8ceb-4f7d-b8fc-59108b4dfbac_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
To avoid changes to existing RADIUS routing procedures, the messages would =
need to be routed to based on the realm in the NAI.&nbsp; <br><br>However, =
the routing requirements for the ERX application are different from those i=
n normal AAA exchanges, because here key state (unlike the AAA credentials =
database) is not replicated.&nbsp;&nbsp; That means that messages can't jus=
t be routed based on a "Domain Identifier" -- they actually have to be addr=
essed to specific servers, since only those servers will hold the required =
key state. <br><br>For example, a "session resume NAI" could identify the s=
pecific EAP Session-Id that is being resumed, as well as the realm in which=
 that key resides.&nbsp; However, an NAI including only the realm will not =
necessarily be routed to the server or proxy that holds the key state, beca=
use AAA deployments often point the authenticators at different AAA servers=
 or proxies for load balancing purposes.&nbsp;&nbsp; To ensure that the req=
uest goes to the right place, the specific server name needs to be provided=
 within the NAI.&nbsp; <br><br>This may not be that easy to produce.&nbsp; =
Not all EAP methods produce the Server-Id, so the peer may not be able to i=
nclude the specific server name in a "session resume NAI" sent to the home =
AAA server.&nbsp; For the peer to compose a "session resume NAI" for the lo=
cal realm, it would have to learn the local server name, not just a "Domain=
 Identifier".&nbsp; <br><br><br>&gt; Date: Mon, 7 Jan 2008 10:54:02 +0200<b=
r>&gt; From: [e-mail]<br>&gt; To: [e-mail]<br>&g=
t; CC: [e-mail]; [e-mail]<br>&gt; Subject: Re: [HOKEY] =
a transparent proposal<br>&gt; <br>&gt; I don't think that this works since=
 the Authenticator needs to route the <br>&gt; messages to a local proxy th=
at later acts as the local ER server. Hence, <br>&gt; the Authenticator nee=
ds to perform special routing functionality. In my <br>&gt; recent mail to =
the list I was wondering whether in Diameter one would <br>&gt; have to def=
ine a new Diameter application for EAP-ER to accomplish this <br>&gt; routi=
ng since otherwise you might encounter other interesting effects.<br>&gt; <=
br>&gt; Ciao<br>&gt; Hannes<br>&gt; <br>&gt; <br>&gt; <br>&gt; <br>&gt; <br=
>&gt; Barney Wolff wrote:<br>&gt; &gt; I've been reading the HOKEY drafts, =
and am somewhat taken aback by<br>&gt; &gt; the extent of the required chan=
ges.  I know it's late in the process,<br>&gt; &gt; but I wonder if the HOK=
EY group has considered and rejected an idea<br>&gt; &gt; like the followin=
g.  If so, why?  If not, and there is some expression<br>&gt; &gt; of suppo=
rt, I could write it up as a draft.<br>&gt; &gt;<br>&gt; &gt; Make HOKEY tr=
ansparent to the authenticator - peer and server have to know,<br>&gt; &gt;=
 but the authenticator does not.<br>&gt; &gt;<br>&gt; &gt; As part of the i=
nitial EAP conversation, peer &amp; server agree that HOKEY may<br>&gt; &gt=
; be done.  The MSK that the server sends to the authenticator is not the<b=
r>&gt; &gt; real MSK, but a domain-authenticator-specific key derived from =
it that<br>&gt; &gt; the peer can also derive.<br>&gt; &gt;<br>&gt; &gt; Wh=
en the peer connects to another authenticator, the identity it<br>&gt; &gt;=
 supplies is a reauth-NAI given to it by the original server rather<br>&gt;=
 &gt; than the id it supplied at initial auth.  Based on the id, the new<br=
>&gt; &gt; authenticator naturally routes its access-requests to a reauth<b=
r>&gt; &gt; server, without needing any code updates.  The reauth server go=
es<br>&gt; &gt; through an abbreviated conversation with the peer, and upon=
 success<br>&gt; &gt; sends the newly-derived domain-authenticator-specific=
 key to the<br>&gt; &gt; authenticator.  Class can be used to tie together =
all the pieces.<br>&gt; &gt;<br>&gt; &gt; Advantages:<br>&gt; &gt;<br>&gt; =
&gt; Authenticator is completely unchanged.<br>&gt; &gt;<br>&gt; &gt; AAA p=
roxies are completely unchanged.<br>&gt; &gt;<br>&gt; &gt; Peer behavior re=
mains that of an EAP responder, rather than being both<br>&gt; &gt; request=
er (for reauth) and responder (for initial auth) in the current<br>&gt; &gt=
; HOKEY drafts.  The HOKEY drafts seem to do considerable philosophical<br>=
&gt; &gt; violence to EAP in this regard.<br>&gt; &gt;<br>&gt; &gt; No new =
EAP codes.  HOKEY can be done as a new EAP method.<br>&gt; &gt;<br>&gt; &gt=
; Disadvantages:<br>&gt; &gt;<br>&gt; &gt; There is an extra round-trip, bu=
t it is to a (presumably local) reauth<br>&gt; &gt; server.  Even that coul=
d be avoided if the authenticator were to be<br>&gt; &gt; upgraded to recog=
nize a reauth-identity and generate a reauth-eap<br>&gt; &gt; request itsel=
f.  But I suspect that's not really necessary.<br>&gt; &gt;<br>&gt; &gt;   =
<br>&gt; <br>&gt; <br>&gt; --<br>&gt; to unsubscribe send a message to radi=
[e-mail] with<br>&gt; the word 'unsubscribe' in a single =
line as the message text body.<br>&gt; archive: &lt;http://psg.com/lists/ra=
diusext/&gt;<br></body>
</html>=

--_534e0f42-8ceb-4f7d-b8fc-59108b4dfbac_--

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Mon, 07 Jan 2008 12:30:30 +0000
Message-ID: <[e-mail]>
Date: Mon, 07 Jan 2008 13:27:56 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Hannes Tschofenig <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: [HOKEY] a transparent proposal
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hannes Tschofenig wrote:
> I don't think that this works since the Authenticator needs to route the
> messages to a local proxy that later acts as the local ER server.

  This scenario already includes roaming users, so the local AAA
server(s) already do realm routing.  Adding one more for a local ER
server shouldn't be major change.

> Hence,
> the Authenticator needs to perform special routing functionality. 

  I don't believe so.  The local *AAA* server needs to perform special
routing.  But as noted above, it already does this.

  Alan DeKok.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Mon, 07 Jan 2008 08:54:39 +0000
Message-ID: <[e-mail]>
Date: Mon, 07 Jan 2008 10:54:02 +0200
From: Hannes Tschofenig <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: [HOKEY] a transparent proposal
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I don't think that this works since the Authenticator needs to route the 
messages to a local proxy that later acts as the local ER server. Hence, 
the Authenticator needs to perform special routing functionality. In my 
recent mail to the list I was wondering whether in Diameter one would 
have to define a new Diameter application for EAP-ER to accomplish this 
routing since otherwise you might encounter other interesting effects.

Ciao
Hannes





Barney Wolff wrote:
> I've been reading the HOKEY drafts, and am somewhat taken aback by
> the extent of the required changes.  I know it's late in the process,
> but I wonder if the HOKEY group has considered and rejected an idea
> like the following.  If so, why?  If not, and there is some expression
> of support, I could write it up as a draft.
>
> Make HOKEY transparent to the authenticator - peer and server have to know,
> but the authenticator does not.
>
> As part of the initial EAP conversation, peer & server agree that HOKEY may
> be done.  The MSK that the server sends to the authenticator is not the
> real MSK, but a domain-authenticator-specific key derived from it that
> the peer can also derive.
>
> When the peer connects to another authenticator, the identity it
> supplies is a reauth-NAI given to it by the original server rather
> than the id it supplied at initial auth.  Based on the id, the new
> authenticator naturally routes its access-requests to a reauth
> server, without needing any code updates.  The reauth server goes
> through an abbreviated conversation with the peer, and upon success
> sends the newly-derived domain-authenticator-specific key to the
> authenticator.  Class can be used to tie together all the pieces.
>
> Advantages:
>
> Authenticator is completely unchanged.
>
> AAA proxies are completely unchanged.
>
> Peer behavior remains that of an EAP responder, rather than being both
> requester (for reauth) and responder (for initial auth) in the current
> HOKEY drafts.  The HOKEY drafts seem to do considerable philosophical
> violence to EAP in this regard.
>
> No new EAP codes.  HOKEY can be done as a new EAP method.
>
> Disadvantages:
>
> There is an extra round-trip, but it is to a (presumably local) reauth
> server.  Even that could be avoided if the authenticator were to be
> upgraded to recognize a reauth-identity and generate a reauth-eap
> request itself.  But I suspect that's not really necessary.
>
>   


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Mon, 07 Jan 2008 08:44:15 +0000
Message-ID: <[e-mail]>
Date: Mon, 07 Jan 2008 10:43:02 +0200
From: Hannes Tschofenig <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: AAA Routing with EAP-ER
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi Bernhard,

Bernard Aboba wrote:
> I think this makes the assumption that every Diameter agent advertising=

> support for the ERX application understands ERX.
That's not really desirable.

>   While Diameter auth=20
> servers do need to understand the application to advertise it, Diameter=
 agents=20
> may only be able to forward the messages. =20
>  =20
Correct.

> =20
> This could become an issue if there is an expectation that the "local s=
erver"
> will process a packet whose NAI realm is not the local realm. =20
Based on my understanding this seems to be the case with EAP-ER.

> Instead of
> processing the packet, the Diameter agent would forward the packet to
> the server corresponding to the NAI realm (e.g. the home server).=20
> =20
> The issue is that there is no equivalent of the "router alert" option f=
or
> AAA.=20
>  =20
I know.

It seems that you are saying that a new Diameter application would be=20
necessary to accomplish the required functionality in a reasonable way.

Ciao
Hannes

> =20
>  =20
>> Date: Fri, 4 Jan 2008 11:56:35 +0100> From: [e-mail]>=
 To: [e-mail]> CC: [e-mail]; [e-mail]=
g> Subject: AAA Routing with EAP-ER> > Working on> http://tools.ietf.org/=
wg/dime/draft-dondeti-dime-erp-diameter-01.txt> the question of defining =
AVPs vs. defining a new Diameter application > showed up.> > I wrote a se=
ction about this into that draft and I wonder whether my > assumptions ar=
e reasonable:> > 3. Assumptions> > This document defines additional optio=
nal AVPs for usage with the> Diameter EAP application. Routing of these m=
essages is therefore> provided via the Diameter Application Identifier (a=
mong other> elements), as specified by the Diameter Base protocol [4]. Ba=
sed on> the deployment of ERP, a local Diameter server (the same entity> =
serves as a Diameter proxy during the full EAP authentication) may> play =
the role of the ER server for future re-authentication attempts.> As such=
, the local Diameter server requesting the DSRK needs to be in> the path =
of the current EAP exchange between the peer and the EAP> server and also=
 along the path in the future. The Diameter client is > furthermore assum=
ed to be able to route the re-authentication > messages to the ER server.=
> > > Depending on some of the answers to the questions raised in this > =
discussion it might be necessary to define a new Diameter application > r=
ather than just defining new AVPs.> > Ciao> Hannes> > > Bernard_Aboba@hot=
mail.com wrote:> >> When the peer, the local domain and the AAA-Home also=
> >> support ERP, a DSRK (DSRK1) may be requested by the local ER server =
A at> >> the time of the EAP exchange.> >> > Some questions:> >> > 1. Is =
the "Local ER server" always a RADIUS client? The ERX > > document seems =
to> > indicate that this might not always be the case.> >> > 2. How is th=
e request for the DSRK made by the "local ER server"? > > Is the> > reque=
st authenticated with user credentials? How does the RADIUS server> > det=
ermine if the Request is valid?> >> > 3. How does the RADIUS server know =
how to reach the "Local ER server"?> > The ERX document talks about a "Do=
main Identity". How does the RADIUS > > server> > use the "Domain Identit=
y" to determine what RADIUS client to send a > > packet to?> > Is there a=
n assumption that the "Local ER server" is one hop away from > > the> > h=
ome RADIUS server? What attributes need to be placed within an > > Access=
-Accept> > to ensure that the packet is routed to the "local server"?> >>=
 > 4. In Figure 1, the ERX document shows the following flow:> >> > [<-- =
EAP-Request/ ------> > Identity]> > [<-- EAP Initiate/ ------> > Reauth-S=
tart]> >> > Is this a typo? The figure shows that the EAP-Request/Identit=
y isn't > > being responded> > to by the peer. If the peer implements RFC=
 3748, won't it send an > > EAP-Response,> > which will be passed to the =
RADIUS server, which will then initiate > > EAP? Figure 1> > seems to sho=
w the EAP peer ignoring the EAP-Request, which> > implies that it needs t=
o wait for some period of time for another > > message, which> > might or=
 might not arrive. How long should it wait?> >> > If the peer doesn't res=
pond to the EAP-Request/Identity, according to > > RFC 3748> > and RFC 41=
37, the NAS will retransmit. So we'll have two EAP > > conversations> > g=
oing on at once?> >> > 5. In Figure 2, the peer is initiating what would =
appear to be a > > standard> > RADIUS/EAP conversation via the EAP-Respon=
se/Identity. However, it> > would appear that the EAP Response/Identity i=
s being "augmented" by> > the local server. It's hard for me to tell from=
 the figure whether the> > [DSRK Req, Domain Identity] is being inserted =
within the > > EAP-Response/Identity,> > or whether it represents separat=
e RADIUS attributes. Can you clarify?> >> > 6. If the "local 'server" isn=
't on the path between the NAS and the > > home server> > (as it might no=
t be, because of failover), what happens? Does each > > proxy> > also nee=
d to host a "local server" to make sure that doesn't occur?> > If the "lo=
cal server" is not on the path, then it seems like two > > distinct messa=
ges> > would be required. Is there an expectation that the RADIUS > > Acc=
ess-Accept> > will be multicast, or that two distinct RADIUS Access-Accep=
t packets will> > be sent?> >> >> >> >> >> >> > -- > > to unsubscribe sen=
d a message to [e-mail] with> > the word 'unsubscri=
be' in a single line as the message text body.> > archive: <http://psg.co=
m/lists/radiusext/>>=20
>>    =20



--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Sun, 06 Jan 2008 23:33:21 +0000
Date: Sun, 6 Jan 2008 18:32:08 -0500
From: Barney Wolff <[e-mail]>
To: [e-mail], [e-mail]
Subject: [HOKEY] a transparent proposal
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.17 (2007-11-01)

I've been reading the HOKEY drafts, and am somewhat taken aback by
the extent of the required changes.  I know it's late in the process,
but I wonder if the HOKEY group has considered and rejected an idea
like the following.  If so, why?  If not, and there is some expression
of support, I could write it up as a draft.

Make HOKEY transparent to the authenticator - peer and server have to know,
but the authenticator does not.

As part of the initial EAP conversation, peer & server agree that HOKEY may
be done.  The MSK that the server sends to the authenticator is not the
real MSK, but a domain-authenticator-specific key derived from it that
the peer can also derive.

When the peer connects to another authenticator, the identity it
supplies is a reauth-NAI given to it by the original server rather
than the id it supplied at initial auth.  Based on the id, the new
authenticator naturally routes its access-requests to a reauth
server, without needing any code updates.  The reauth server goes
through an abbreviated conversation with the peer, and upon success
sends the newly-derived domain-authenticator-specific key to the
authenticator.  Class can be used to tie together all the pieces.

Advantages:

Authenticator is completely unchanged.

AAA proxies are completely unchanged.

Peer behavior remains that of an EAP responder, rather than being both
requester (for reauth) and responder (for initial auth) in the current
HOKEY drafts.  The HOKEY drafts seem to do considerable philosophical
violence to EAP in this regard.

No new EAP codes.  HOKEY can be done as a new EAP method.

Disadvantages:

There is an extra round-trip, but it is to a (presumably local) reauth
server.  Even that could be avoided if the authenticator were to be
upgraded to recognize a reauth-identity and generate a reauth-eap
request itself.  But I suspect that's not really necessary.

-- 
Barney Wolff         I never met a computer I didn't like.


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Sun, 06 Jan 2008 07:10:19 +0000
Message-ID: <[e-mail]>
Date: Sun, 06 Jan 2008 08:08:03 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Lakshminath Dondeti <[e-mail]>
CC: Yoshihiro Ohba <[e-mail]>, [e-mail],  radext mailing list <[e-mail]>
Subject: Re: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

Lakshminath Dondeti wrote:
> Isn't there a solution on the table already with DTLS proposal?

  No.  RADIUS + DTLS is still hop by hop.  There are no provisions in it
for end to end security.

  Alan DeKok.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Sun, 06 Jan 2008 06:27:22 +0000
Date: Sun, 6 Jan 2008 01:25:35 -0500
From: Yoshihiro Ohba <[e-mail]>
To: Lakshminath Dondeti <[e-mail]>
Cc: Dan Harkins <[e-mail]>, [e-mail], radext mailing list <[e-mail]>
Subject: Re: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Disposition: inline
User-Agent: Mutt/1.5.17 (2007-11-01)

Do you mean DTLS-SRTP or something else?  In the former case, I'm not
sure how it works with AAA proxies.

Yoshihiro Ohba


On Sat, Jan 05, 2008 at 06:33:12PM -0800, Lakshminath Dondeti wrote:
> Isn't there a solution on the table already with DTLS proposal?
>
> Lakshminath
>
> On 1/5/2008 3:31 PM, Yoshihiro Ohba wrote:
>> Why just not use inter-realm Kerberos to establish an end-to-end SA
>> between EAP server and DSR-KH, and then do DSRK distribution over the
>> established SA?  Inter-realm Kerberos works with chain of trust and
>> should work with the case where AAA proxies are between EAP server and
>> DSR-KH.  The past proposal about Kerberos over RADIUS indicated by
>> Bernard sounds like a good solution.
>>
>> Yoshihiro Ohba
>>
>> On Sat, Jan 05, 2008 at 11:22:41AM -0800, Lakshminath Dondeti wrote:
>>> The key however is that there was no real mechanism for end-to-end 
>>> security that 4568 might recommend and now RAI is in another iteration 
>>> for key management for SRTP.
>>>
>>> Lakshminath
>>>
>>> On 1/5/2008 11:13 AM, Yoshihiro Ohba wrote:
>>>> Lakshminath,
>>>>
>>>> Thank you for the pointer to RFC 4568.
>>>>
>>>> In my reading of RFC 4568, it recommends end-to-end security when the
>>>> communication path of the SDP message is routed through intermediate
>>>> systems like SIP proxies.  IMO, end-to-end security (with Type 1
>>>> trust) should be the default model for any key distribution mechanism
>>>> even if hop-by-hop security is not totally prohibited for some use
>>>> cases.  Yoshihiro Ohba
>>>>
>>>>
>>>>
>>>> On Fri, Jan 04, 2008 at 04:58:42PM -0800, Lakshminath Dondeti wrote:
>>>>> Hi Yoshi,
>>>>>
>>>>> You are on the right track by exploring the implications of hop-by-hop 
>>>>> security.  In the case we are talking about, it may result in billing 
>>>>> inconsistencies.  That we have agreed is ok in some cases and perhaps 
>>>>> not ok in others.  This is a reasonable conclusion as illustrated 
>>>>> elsewhere:  In case of SIP proxies, hop-by-hop security implies that 
>>>>> proxies may be able to compromise end-to-end user data/media 
>>>>> confidentiality.  In this case, end-to-end security may be compromised 
>>>>> and we have an assortment of techniques at the IETF to deal with the 
>>>>> problem.  The proxy model is allowed however.  There are key 
>>>>> distribution mechanisms (RFC 4568) which work with the proxy model in 
>>>>> mind.
>>>>>
>>>>> best wishes for 2008,
>>>>> Lakshminath
>>>>>
>>>>> On 1/4/2008 4:27 PM, Yoshihiro Ohba wrote:
>>>>>> I can see two conflicting types of trust for hop-by-hop security to
>>>>>> work.
>>>>>>
>>>>>> Type 1 trust: Trusted entities can use any keys that they have access
>>>>>> to, regardless of how they are distributed.
>>>>>>
>>>>>> Type 2 trust: Trusted entities will not use keys distributed to others
>>>>>> even if they have access to the keys.
>>>>>>
>>>>>> In Type 1 trust, multiple trusted entities are actually sharing keys
>>>>>> for use, and thus key hierarchy is not needed.  In Type 2 trust, key 
>>>>>> hierarchy is still needed.  Also, there is no
>>>>>> Type 2 trust in end-to-end security.  To me, Type 2 trust is similar
>>>>>> to a real-world case where we need to trust how a check-in baggage
>>>>>> will be inspected and treated once it is checked in.  Inspectors have
>>>>>> the right to access to the baggage contents for the purpose of airline
>>>>>> security, but airline customers (need to) trust them that they will
>>>>>> not use the contents.
>>>>>>
>>>>>> The issue seems to be which trust model (or something else) is
>>>>>> acceptable for us.  In my personal opinion, Type 2 trust is not
>>>>>> desirable from security perspective, unless AAA proxies really need to
>>>>>> access to the keys to improve AAA secuirty.
>>>>>>
>>>>>> Yoshihiro Ohba
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jan 04, 2008 at 11:37:43AM -0800, Dan Harkins wrote:
>>>>>>>   Hi Lakshminath,
>>>>>>>
>>>>>>> On Fri, January 4, 2008 8:58 am, Lakshminath Dondeti wrote:
>>>>>>> [snip]
>>>>>>>> Hi Dan,
>>>>>>>>
>>>>>>>> I am trying to understand the direction of the discussion here:
>>>>>>>>
>>>>>>>> When there is end-to-end security, it appears that we have agreement
>>>>>>>> that a key hierarchy is necessary.
>>>>>>>   No, that's not what I'm saying.
>>>>>>>
>>>>>>>> When there is hop-by-hop security, you are making the argument that the
>>>>>>>> DSRK hierarchy is not necessary and that we can use other techniques to
>>>>>>>> make things work.  Isn't it simpler to have the same key hierarchy
>>>>>>>> irrespective of the protection policies in the AAA network?  Besides,
>>>>>>>> the different DSRKs would allow the peer to help the home network verify
>>>>>>>> the accounting information, for instance.
>>>>>>>   We have to deal with the system holistically and not dissect it into
>>>>>>> parts and quibble over "hop-by-hop" or "end-to-end" and whether they apply
>>>>>>> to one part or the other. The issue is what is the threat model for the
>>>>>>> holistic system?
>>>>>>>
>>>>>>>   If proxies are permitted, and they are, then the problems they introduce
>>>>>>> have to be accepted. We have consensus to do that. It is my contention
>>>>>>> that the key hierarchy attempts to address those problems that we have
>>>>>>> already accepted into our system due to proxies so I feel the key
>>>>>>> hierarchy is an unnecessary complexity.
>>>>>>>
>>>>>>>   Of course I may be all wrong. If someone could just tell me exactly
>>>>>>> what problem will completely go away by having this key hierarchy I would
>>>>>>> greatly appreciate it. Can you tell me?
>>>>>>>
>>>>>>>> We talked about the reasoning for the DSRK hierarchy for a long time and
>>>>>>>> achieved consensus.  I understand that you are bringing up these
>>>>>>>> questions again with the hop-by-hop security model in mind.
>>>>>>>   The goalposts have moved. The discussion about the key hierarchy was
>>>>>>> held back when we were still arguing over a 3 party protocol. That was
>>>>>>> when disclosure of keys to people who are not the intended recipient
>>>>>>> was a problem we were going to address. But I have come to the realization
>>>>>>> that the working group is not interested in a protocol that could not work
>>>>>>> in the presence of proxies and that the working group now feels that that
>>>>>>> problem is not something that needs addressing.
>>>>>>>
>>>>>>>   I believe that the problems that proxies introduce are the same ones that
>>>>>>> arise when a key is shared between domains. The key hierarchy addresses the
>>>>>>> latter but not the former. Since WG consensus is that the former is not
>>>>>>> something that needs addressing I question why the latter needs addressing.
>>>>>>>
>>>>>>>   A counter example would go a long way to justifying the key hierarchy.
>>>>>>> Do you have one?
>>>>>>>
>>>>>>>>                                                              Personally,
>>>>>>>> I find it instructive to think about the implications of putting trust
>>>>>>>> in proxies.  We discussed that in Vancouver and noted that billing
>>>>>>>> inconsistencies may be the result.  If an operator is willing to handle
>>>>>>>> those through non-protocol means (and that's what many do today), we
>>>>>>>> should continue to allow that model of operation.
>>>>>>>   I'm not saying we shouldn't allow that model of operation. In fact,
>>>>>>> I am acknowledging that the WG has consensus to allow it.
>>>>>>>
>>>>>>>   What I am saying is that by allowing that model of operation we are
>>>>>>> agreeing to not address the problems it introduces. And that being the
>>>>>>> case the key hierarchy becomes extraneous, an unnecessary complexity
>>>>>>> that we should just do away with.
>>>>>>>
>>>>>>>> best wishes for the new year,
>>>>>>>> Lakshminath
>>>>>>>   Thank you very much! I hope you have a great 2008.
>>>>>>>
>>>>>>>   Dan.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> HOKEY mailing list
>>>>>>> [e-mail]
>>>>>>> https://www1.ietf.org/mailman/listinfo/hokey
>>>>>>>
>>>>>>>
>>>>>>>
>>
>

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Sat, 05 Jan 2008 23:35:48 +0000
Date: Sat, 5 Jan 2008 18:31:05 -0500
From: Yoshihiro Ohba <[e-mail]>
To: Lakshminath Dondeti <[e-mail]>
Cc: Dan Harkins <[e-mail]>, [e-mail], radext mailing list <[e-mail]>
Subject: Re: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Disposition: inline
User-Agent: Mutt/1.5.17 (2007-11-01)

Why just not use inter-realm Kerberos to establish an end-to-end SA
between EAP server and DSR-KH, and then do DSRK distribution over the
established SA?  Inter-realm Kerberos works with chain of trust and
should work with the case where AAA proxies are between EAP server and
DSR-KH.  The past proposal about Kerberos over RADIUS indicated by
Bernard sounds like a good solution.

Yoshihiro Ohba

On Sat, Jan 05, 2008 at 11:22:41AM -0800, Lakshminath Dondeti wrote:
> The key however is that there was no real mechanism for end-to-end security 
> that 4568 might recommend and now RAI is in another iteration for key 
> management for SRTP.
>
> Lakshminath
>
> On 1/5/2008 11:13 AM, Yoshihiro Ohba wrote:
>> Lakshminath,
>>
>> Thank you for the pointer to RFC 4568.
>>
>> In my reading of RFC 4568, it recommends end-to-end security when the
>> communication path of the SDP message is routed through intermediate
>> systems like SIP proxies.  IMO, end-to-end security (with Type 1
>> trust) should be the default model for any key distribution mechanism
>> even if hop-by-hop security is not totally prohibited for some use
>> cases.  
>> Yoshihiro Ohba
>>
>>
>>
>> On Fri, Jan 04, 2008 at 04:58:42PM -0800, Lakshminath Dondeti wrote:
>>> Hi Yoshi,
>>>
>>> You are on the right track by exploring the implications of hop-by-hop 
>>> security.  In the case we are talking about, it may result in billing 
>>> inconsistencies.  That we have agreed is ok in some cases and perhaps not 
>>> ok in others.  This is a reasonable conclusion as illustrated elsewhere:  
>>> In case of SIP proxies, hop-by-hop security implies that proxies may be 
>>> able to compromise end-to-end user data/media confidentiality.  In this 
>>> case, end-to-end security may be compromised and we have an assortment of 
>>> techniques at the IETF to deal with the problem.  The proxy model is 
>>> allowed however.  There are key distribution mechanisms (RFC 4568) which 
>>> work with the proxy model in mind.
>>>
>>> best wishes for 2008,
>>> Lakshminath
>>>
>>> On 1/4/2008 4:27 PM, Yoshihiro Ohba wrote:
>>>> I can see two conflicting types of trust for hop-by-hop security to
>>>> work.
>>>>
>>>> Type 1 trust: Trusted entities can use any keys that they have access
>>>> to, regardless of how they are distributed.
>>>>
>>>> Type 2 trust: Trusted entities will not use keys distributed to others
>>>> even if they have access to the keys.
>>>>
>>>> In Type 1 trust, multiple trusted entities are actually sharing keys
>>>> for use, and thus key hierarchy is not needed.  In Type 2 trust, key 
>>>> hierarchy is still needed.  Also, there is no
>>>> Type 2 trust in end-to-end security.  To me, Type 2 trust is similar
>>>> to a real-world case where we need to trust how a check-in baggage
>>>> will be inspected and treated once it is checked in.  Inspectors have
>>>> the right to access to the baggage contents for the purpose of airline
>>>> security, but airline customers (need to) trust them that they will
>>>> not use the contents.
>>>>
>>>> The issue seems to be which trust model (or something else) is
>>>> acceptable for us.  In my personal opinion, Type 2 trust is not
>>>> desirable from security perspective, unless AAA proxies really need to
>>>> access to the keys to improve AAA secuirty.
>>>>
>>>> Yoshihiro Ohba
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Jan 04, 2008 at 11:37:43AM -0800, Dan Harkins wrote:
>>>>>   Hi Lakshminath,
>>>>>
>>>>> On Fri, January 4, 2008 8:58 am, Lakshminath Dondeti wrote:
>>>>> [snip]
>>>>>> Hi Dan,
>>>>>>
>>>>>> I am trying to understand the direction of the discussion here:
>>>>>>
>>>>>> When there is end-to-end security, it appears that we have agreement
>>>>>> that a key hierarchy is necessary.
>>>>>   No, that's not what I'm saying.
>>>>>
>>>>>> When there is hop-by-hop security, you are making the argument that the
>>>>>> DSRK hierarchy is not necessary and that we can use other techniques to
>>>>>> make things work.  Isn't it simpler to have the same key hierarchy
>>>>>> irrespective of the protection policies in the AAA network?  Besides,
>>>>>> the different DSRKs would allow the peer to help the home network verify
>>>>>> the accounting information, for instance.
>>>>>   We have to deal with the system holistically and not dissect it into
>>>>> parts and quibble over "hop-by-hop" or "end-to-end" and whether they apply
>>>>> to one part or the other. The issue is what is the threat model for the
>>>>> holistic system?
>>>>>
>>>>>   If proxies are permitted, and they are, then the problems they introduce
>>>>> have to be accepted. We have consensus to do that. It is my contention
>>>>> that the key hierarchy attempts to address those problems that we have
>>>>> already accepted into our system due to proxies so I feel the key
>>>>> hierarchy is an unnecessary complexity.
>>>>>
>>>>>   Of course I may be all wrong. If someone could just tell me exactly
>>>>> what problem will completely go away by having this key hierarchy I would
>>>>> greatly appreciate it. Can you tell me?
>>>>>
>>>>>> We talked about the reasoning for the DSRK hierarchy for a long time and
>>>>>> achieved consensus.  I understand that you are bringing up these
>>>>>> questions again with the hop-by-hop security model in mind.
>>>>>   The goalposts have moved. The discussion about the key hierarchy was
>>>>> held back when we were still arguing over a 3 party protocol. That was
>>>>> when disclosure of keys to people who are not the intended recipient
>>>>> was a problem we were going to address. But I have come to the realization
>>>>> that the working group is not interested in a protocol that could not work
>>>>> in the presence of proxies and that the working group now feels that that
>>>>> problem is not something that needs addressing.
>>>>>
>>>>>   I believe that the problems that proxies introduce are the same ones that
>>>>> arise when a key is shared between domains. The key hierarchy addresses the
>>>>> latter but not the former. Since WG consensus is that the former is not
>>>>> something that needs addressing I question why the latter needs addressing.
>>>>>
>>>>>   A counter example would go a long way to justifying the key hierarchy.
>>>>> Do you have one?
>>>>>
>>>>>>                                                              Personally,
>>>>>> I find it instructive to think about the implications of putting trust
>>>>>> in proxies.  We discussed that in Vancouver and noted that billing
>>>>>> inconsistencies may be the result.  If an operator is willing to handle
>>>>>> those through non-protocol means (and that's what many do today), we
>>>>>> should continue to allow that model of operation.
>>>>>   I'm not saying we shouldn't allow that model of operation. In fact,
>>>>> I am acknowledging that the WG has consensus to allow it.
>>>>>
>>>>>   What I am saying is that by allowing that model of operation we are
>>>>> agreeing to not address the problems it introduces. And that being the
>>>>> case the key hierarchy becomes extraneous, an unnecessary complexity
>>>>> that we should just do away with.
>>>>>
>>>>>> best wishes for the new year,
>>>>>> Lakshminath
>>>>>   Thank you very much! I hope you have a great 2008.
>>>>>
>>>>>   Dan.
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> HOKEY mailing list
>>>>> [e-mail]
>>>>> https://www1.ietf.org/mailman/listinfo/hokey
>>>>>
>>>>>
>>>>>
>>>
>>
>

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Sat, 05 Jan 2008 19:16:40 +0000
Date: Sat, 5 Jan 2008 14:13:59 -0500
From: Yoshihiro Ohba <[e-mail]>
To: Lakshminath Dondeti <[e-mail]>
Cc: Dan Harkins <[e-mail]>, [e-mail], radext mailing list <[e-mail]>
Subject: Re: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Disposition: inline
User-Agent: Mutt/1.5.17 (2007-11-01)

Lakshminath,

Thank you for the pointer to RFC 4568.

In my reading of RFC 4568, it recommends end-to-end security when the
communication path of the SDP message is routed through intermediate
systems like SIP proxies.  IMO, end-to-end security (with Type 1
trust) should be the default model for any key distribution mechanism
even if hop-by-hop security is not totally prohibited for some use
cases.  

Yoshihiro Ohba



On Fri, Jan 04, 2008 at 04:58:42PM -0800, Lakshminath Dondeti wrote:
> Hi Yoshi,
>
> You are on the right track by exploring the implications of hop-by-hop 
> security.  In the case we are talking about, it may result in billing 
> inconsistencies.  That we have agreed is ok in some cases and perhaps not 
> ok in others.  This is a reasonable conclusion as illustrated elsewhere:  
> In case of SIP proxies, hop-by-hop security implies that proxies may be 
> able to compromise end-to-end user data/media confidentiality.  In this 
> case, end-to-end security may be compromised and we have an assortment of 
> techniques at the IETF to deal with the problem.  The proxy model is 
> allowed however.  There are key distribution mechanisms (RFC 4568) which 
> work with the proxy model in mind.
>
> best wishes for 2008,
> Lakshminath
>
> On 1/4/2008 4:27 PM, Yoshihiro Ohba wrote:
>> I can see two conflicting types of trust for hop-by-hop security to
>> work.
>>
>> Type 1 trust: Trusted entities can use any keys that they have access
>> to, regardless of how they are distributed.
>>
>> Type 2 trust: Trusted entities will not use keys distributed to others
>> even if they have access to the keys.
>>
>> In Type 1 trust, multiple trusted entities are actually sharing keys
>> for use, and thus key hierarchy is not needed.  
>> In Type 2 trust, key hierarchy is still needed.  Also, there is no
>> Type 2 trust in end-to-end security.  To me, Type 2 trust is similar
>> to a real-world case where we need to trust how a check-in baggage
>> will be inspected and treated once it is checked in.  Inspectors have
>> the right to access to the baggage contents for the purpose of airline
>> security, but airline customers (need to) trust them that they will
>> not use the contents.
>>
>> The issue seems to be which trust model (or something else) is
>> acceptable for us.  In my personal opinion, Type 2 trust is not
>> desirable from security perspective, unless AAA proxies really need to
>> access to the keys to improve AAA secuirty.
>>
>> Yoshihiro Ohba
>>
>>
>>
>>
>> On Fri, Jan 04, 2008 at 11:37:43AM -0800, Dan Harkins wrote:
>>>   Hi Lakshminath,
>>>
>>> On Fri, January 4, 2008 8:58 am, Lakshminath Dondeti wrote:
>>> [snip]
>>>> Hi Dan,
>>>>
>>>> I am trying to understand the direction of the discussion here:
>>>>
>>>> When there is end-to-end security, it appears that we have agreement
>>>> that a key hierarchy is necessary.
>>>   No, that's not what I'm saying.
>>>
>>>> When there is hop-by-hop security, you are making the argument that the
>>>> DSRK hierarchy is not necessary and that we can use other techniques to
>>>> make things work.  Isn't it simpler to have the same key hierarchy
>>>> irrespective of the protection policies in the AAA network?  Besides,
>>>> the different DSRKs would allow the peer to help the home network verify
>>>> the accounting information, for instance.
>>>   We have to deal with the system holistically and not dissect it into
>>> parts and quibble over "hop-by-hop" or "end-to-end" and whether they apply
>>> to one part or the other. The issue is what is the threat model for the
>>> holistic system?
>>>
>>>   If proxies are permitted, and they are, then the problems they introduce
>>> have to be accepted. We have consensus to do that. It is my contention
>>> that the key hierarchy attempts to address those problems that we have
>>> already accepted into our system due to proxies so I feel the key
>>> hierarchy is an unnecessary complexity.
>>>
>>>   Of course I may be all wrong. If someone could just tell me exactly
>>> what problem will completely go away by having this key hierarchy I would
>>> greatly appreciate it. Can you tell me?
>>>
>>>> We talked about the reasoning for the DSRK hierarchy for a long time and
>>>> achieved consensus.  I understand that you are bringing up these
>>>> questions again with the hop-by-hop security model in mind.
>>>   The goalposts have moved. The discussion about the key hierarchy was
>>> held back when we were still arguing over a 3 party protocol. That was
>>> when disclosure of keys to people who are not the intended recipient
>>> was a problem we were going to address. But I have come to the realization
>>> that the working group is not interested in a protocol that could not work
>>> in the presence of proxies and that the working group now feels that that
>>> problem is not something that needs addressing.
>>>
>>>   I believe that the problems that proxies introduce are the same ones that
>>> arise when a key is shared between domains. The key hierarchy addresses the
>>> latter but not the former. Since WG consensus is that the former is not
>>> something that needs addressing I question why the latter needs addressing.
>>>
>>>   A counter example would go a long way to justifying the key hierarchy.
>>> Do you have one?
>>>
>>>>                                                              Personally,
>>>> I find it instructive to think about the implications of putting trust
>>>> in proxies.  We discussed that in Vancouver and noted that billing
>>>> inconsistencies may be the result.  If an operator is willing to handle
>>>> those through non-protocol means (and that's what many do today), we
>>>> should continue to allow that model of operation.
>>>   I'm not saying we shouldn't allow that model of operation. In fact,
>>> I am acknowledging that the WG has consensus to allow it.
>>>
>>>   What I am saying is that by allowing that model of operation we are
>>> agreeing to not address the problems it introduces. And that being the
>>> case the key hierarchy becomes extraneous, an unnecessary complexity
>>> that we should just do away with.
>>>
>>>> best wishes for the new year,
>>>> Lakshminath
>>>   Thank you very much! I hope you have a great 2008.
>>>
>>>   Dan.
>>>
>>>
>>>
>>> _______________________________________________
>>> HOKEY mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/hokey
>>>
>>>
>>>
>>
>
>

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Sat, 05 Jan 2008 01:26:06 +0000
DomainKey-Signature: s=qcdkim; d=qualcomm.com; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:Received:Received: X-MimeOLE:Content-class:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:Date:Message-ID: In-Reply-To:X-MS-Has-Attach:X-MS-TNEF-Correlator: Thread-Topic:Thread-Index:References:From:To:Cc: X-OriginalArrivalTime; b=qAgqrkF2wTR4OTXmgdMIEzVtqjJUyeYB1cc8Wf8mK4ZebUleOKoZla59 +MoRoVIrlwJddxcVp+q2AjF7zGSPRqO+/qBh+NwEmnxsuLUtFkt9ETWIj K+6LZIc+GgUFv8VGQXjXjCOBzNLFIQb2cz2JnK6/unRNJJmDjxme5WZeV I=;
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
Date: Fri, 4 Jan 2008 17:24:46 -0800
Message-ID: <[e-mail]>
Thread-Topic: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
Thread-Index: AchOqWwqW36f0dOLSmOA8haeg7FMYQAialwQ
From: "Narayanan, Vidya" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>

Hi Bernard,

> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of=20
> [e-mail]
> Sent: Friday, January 04, 2008 12:11 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
>=20
> >When the peer, the local domain and the AAA-Home also =20
> support ERP, a=20
> >DSRK (DSRK1) may be requested by the local ER server A at =20
> the time of=20
> >the EAP exchange.
>=20
> Some questions:
>=20
> 1. Is the  "Local ER server" always a RADIUS client? =20

Yes, it is both a client and a server.  It is a client from the
perspective that it requests for the key material from a RADIUS server
and a server from the perspective that it will later serve NASs during
reauthentication.=20

> The=20
> ERX document=20
> seems to
> indicate that this might not always be the case.
>=20

Could you please point out where?  I just scanned the ERX document and
except for describing a specific security consideration with the use of
RADIUS, the document only seems to have pointers to the RADIUS and
Diameter documents.  Perhaps I missed it. =20

> 2.  How is the request for the DSRK made by the "local ER=20
> server"?    Is the
> request authenticated with user credentials?  How does the=20
> RADIUS server determine if the Request is valid?
>=20

The request for DSRK is made with a RADIUS attribute or Diameter AVP in
an ERP bootstrapping exchange initiated by the peer or the first EAP
Response message coming from the peer in a regular EAP exchange.  The
EAP or ERP exchange authenticates the peer and upon successful
authentication, a DSRK is included along with ER Finish or EAP Success
for the local ER server.  This is not much unlike providing the MSK to
the NAS, except that there is no explicit request for an MSK. =20

> 3. How does the RADIUS server know how to reach the "Local ER server"?
> The ERX document talks about a "Domain Identity".  How does=20
> the RADIUS server use the "Domain Identity" to determine what=20
> RADIUS client to send a packet to?
> Is there an assumption that the "Local ER server" is one hop=20
> away from the home RADIUS server?  What attributes need to be=20
> placed within an Access-Accept to ensure that the packet is=20
> routed to the "local server"?
>=20

The local ER server must be in the path of the full EAP exchange or the
ERP bootstrapping exchange of the peer in order to request and receive a
DSRK.  This text was present in draft-gaonkar-radext-erp-attrs-01 and I
notice that it is missing in 02.  We will fix that.  The packet is
routed just using regular AAA routing - the requesting entity's identity
is part of the attribute defined, which will provide an FQDN or IP
address of the local ER server requesting the key - this is present in
the Access-Accept as well.  The local ER server that requested the DSRK
will look for this attribute in the Access-Accept. =20

> 4.  In Figure 1, the ERX document shows the following flow:
>=20
>     [<-- EAP-Request/ ------
>         Identity]
>     [<-- EAP Initiate/ ------
>         Reauth-Start]
>=20
> Is this a typo?  The figure shows that the=20
> EAP-Request/Identity isn't being responded to by the peer. =20
> If the peer implements RFC 3748, won't it send an=20
> EAP-Response, which will be passed to the RADIUS server,=20
> which will then initiate EAP?=20

The idea behind sending both EAP-Request/Identity and
EAP-Initiate/Reauth-Start is that the network can initiate regular EAP
or re-authentication when it wants.  A peer that supports ERX and
possesses a valid EMSK should respond only to the
EAP-Initiate/Reauth-Start.  The EAP process may timeout or the
authenticator, upon receiving the EAP-Initiate/Reauth-Start may
terminate EAP. =20

> Figure 1
> seems to show the EAP peer ignoring the EAP-Request, which=20
> implies that it needs to wait for some period of time for=20
> another message, which
> might or might not arrive.   How long should it wait?
>=20

Not sure why the peer would wait.. It sees that the authenticator
supports ERX and knows that it possesses a valid EMSK - so, it just
proceeds with the ERP exchange.=20

> If the peer doesn't respond to the EAP-Request/Identity,=20
> according to RFC
> 3748
> and RFC 4137, the NAS will retransmit.  So we'll have two EAP=20
> conversations going on at once?
>=20

As I note above, the authenticator may retransmit the
EAP-Request/Identity, in which case it will timeout or it may terminate
EAP when it receives the EAP-Initiate/Reauth-Start.  A smart
implementation should do the latter.  Even upon retransmission of the
EAP-Request/Identity, there isn't really an issue, since, the identifier
for EAP-Initiate is picked by the peer.  Hence, the EAP code (Initiate),
along with the identifier value, will distinguish this exchange from an
EAP-Request transmitted by the authenticator. =20

> 5. In Figure 2,  the peer is initiating what would appear to=20
> be a standard
> RADIUS/EAP conversation via the EAP-Response/Identity.   However, it
> would appear that the EAP Response/Identity is being=20
> "augmented" by the local server.  It's hard for me to tell=20
> from the figure whether the [DSRK Req, Domain Identity] is=20
> being inserted within the EAP-Response/Identity, or whether=20
> it represents separate RADIUS attributes.  Can you clarify?
>=20

It represents separate RADIUS attributes.=20

> 6. If the "local 'server" isn't on the path between the NAS=20
> and the home server
> (as it might not be, because of failover), what happens?  =20
> Does each proxy
> also need to host a "local server" to make sure that doesn't occur?
> If the "local server" is not on the path, then it seems like=20
> two distinct messages
> would be required.   Is there an expectation that the RADIUS=20
> Access-Accept
> will be multicast, or that two distinct RADIUS Access-Accept=20
> packets will be sent?
>=20
>=20

As written, the protocol only supports the case where the local ER
server is in the path between the NAS and home server.  There was some
interest in later supporting the case where it is not in the path, but
there is no proposal to support that option now.=20

Thanks,
Vidya

>=20
> =20
>=20
>=20
> --
> to unsubscribe send a message to=20
> [e-mail] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Sat, 05 Jan 2008 00:29:11 +0000
Date: Fri, 4 Jan 2008 19:27:44 -0500
From: Yoshihiro Ohba <[e-mail]>
To: Dan Harkins <[e-mail]>
Cc: Lakshminath Dondeti <[e-mail]>, [e-mail], radext mailing list <[e-mail]>
Subject: Re: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Disposition: inline
User-Agent: Mutt/1.5.17 (2007-11-01)

I can see two conflicting types of trust for hop-by-hop security to
work.

Type 1 trust: Trusted entities can use any keys that they have access
to, regardless of how they are distributed.

Type 2 trust: Trusted entities will not use keys distributed to others
even if they have access to the keys.

In Type 1 trust, multiple trusted entities are actually sharing keys
for use, and thus key hierarchy is not needed.  

In Type 2 trust, key hierarchy is still needed.  Also, there is no
Type 2 trust in end-to-end security.  To me, Type 2 trust is similar
to a real-world case where we need to trust how a check-in baggage
will be inspected and treated once it is checked in.  Inspectors have
the right to access to the baggage contents for the purpose of airline
security, but airline customers (need to) trust them that they will
not use the contents.

The issue seems to be which trust model (or something else) is
acceptable for us.  In my personal opinion, Type 2 trust is not
desirable from security perspective, unless AAA proxies really need to
access to the keys to improve AAA secuirty.

Yoshihiro Ohba




On Fri, Jan 04, 2008 at 11:37:43AM -0800, Dan Harkins wrote:
> 
>   Hi Lakshminath,
> 
> On Fri, January 4, 2008 8:58 am, Lakshminath Dondeti wrote:
> [snip]
> > Hi Dan,
> >
> > I am trying to understand the direction of the discussion here:
> >
> > When there is end-to-end security, it appears that we have agreement
> > that a key hierarchy is necessary.
> 
>   No, that's not what I'm saying.
> 
> > When there is hop-by-hop security, you are making the argument that the
> > DSRK hierarchy is not necessary and that we can use other techniques to
> > make things work.  Isn't it simpler to have the same key hierarchy
> > irrespective of the protection policies in the AAA network?  Besides,
> > the different DSRKs would allow the peer to help the home network verify
> > the accounting information, for instance.
> 
>   We have to deal with the system holistically and not dissect it into
> parts and quibble over "hop-by-hop" or "end-to-end" and whether they apply
> to one part or the other. The issue is what is the threat model for the
> holistic system?
> 
>   If proxies are permitted, and they are, then the problems they introduce
> have to be accepted. We have consensus to do that. It is my contention
> that the key hierarchy attempts to address those problems that we have
> already accepted into our system due to proxies so I feel the key
> hierarchy is an unnecessary complexity.
> 
>   Of course I may be all wrong. If someone could just tell me exactly
> what problem will completely go away by having this key hierarchy I would
> greatly appreciate it. Can you tell me?
> 
> > We talked about the reasoning for the DSRK hierarchy for a long time and
> > achieved consensus.  I understand that you are bringing up these
> > questions again with the hop-by-hop security model in mind.
> 
>   The goalposts have moved. The discussion about the key hierarchy was
> held back when we were still arguing over a 3 party protocol. That was
> when disclosure of keys to people who are not the intended recipient
> was a problem we were going to address. But I have come to the realization
> that the working group is not interested in a protocol that could not work
> in the presence of proxies and that the working group now feels that that
> problem is not something that needs addressing.
> 
>   I believe that the problems that proxies introduce are the same ones that
> arise when a key is shared between domains. The key hierarchy addresses the
> latter but not the former. Since WG consensus is that the former is not
> something that needs addressing I question why the latter needs addressing.
> 
>   A counter example would go a long way to justifying the key hierarchy.
> Do you have one?
> 
> >                                                              Personally,
> > I find it instructive to think about the implications of putting trust
> > in proxies.  We discussed that in Vancouver and noted that billing
> > inconsistencies may be the result.  If an operator is willing to handle
> > those through non-protocol means (and that's what many do today), we
> > should continue to allow that model of operation.
> 
>   I'm not saying we shouldn't allow that model of operation. In fact,
> I am acknowledging that the WG has consensus to allow it.
> 
>   What I am saying is that by allowing that model of operation we are
> agreeing to not address the problems it introduces. And that being the
> case the key hierarchy becomes extraneous, an unnecessary complexity
> that we should just do away with.
> 
> > best wishes for the new year,
> > Lakshminath
> 
>   Thank you very much! I hope you have a great 2008.
> 
>   Dan.
> 
> 
> 
> _______________________________________________
> HOKEY mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/hokey
> 
> 
> 

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 04 Jan 2008 23:51:35 +0000
From: "Glen Zorn" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: test
Date: Fri, 4 Jan 2008 15:49:52 -0800
Message-ID: <00a501c84f2c$80c48fe0$824dafa0$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A6_01C84EE9.72A14FE0"
Thread-Index: AchPLIALvFYXq5x1Qp2ORzI5Mpvmkw==
Content-Language: en-us

This is a multipart message in MIME format.

------=_NextPart_000_00A6_01C84EE9.72A14FE0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

 


------=_NextPart_000_00A6_01C84EE9.72A14FE0
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</body>

</html>

------=_NextPart_000_00A6_01C84EE9.72A14FE0--


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 04 Jan 2008 19:38:48 +0000
Message-ID: <[e-mail]>
Date: Fri, 4 Jan 2008 11:37:43 -0800 (PST)
Subject: Re: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
From: "Dan Harkins" <[e-mail]>
To: "Lakshminath Dondeti" <[e-mail]>
Cc: "Dan Harkins" <[e-mail]>, "Narayanan, Vidya" <[e-mail]>, "radext mailing list" <[e-mail]>, [e-mail]
User-Agent: SquirrelMail/1.4.8
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit

  Hi Lakshminath,

On Fri, January 4, 2008 8:58 am, Lakshminath Dondeti wrote:
[snip]
> Hi Dan,
>
> I am trying to understand the direction of the discussion here:
>
> When there is end-to-end security, it appears that we have agreement
> that a key hierarchy is necessary.

  No, that's not what I'm saying.

> When there is hop-by-hop security, you are making the argument that the
> DSRK hierarchy is not necessary and that we can use other techniques to
> make things work.  Isn't it simpler to have the same key hierarchy
> irrespective of the protection policies in the AAA network?  Besides,
> the different DSRKs would allow the peer to help the home network verify
> the accounting information, for instance.

  We have to deal with the system holistically and not dissect it into
parts and quibble over "hop-by-hop" or "end-to-end" and whether they apply
to one part or the other. The issue is what is the threat model for the
holistic system?

  If proxies are permitted, and they are, then the problems they introduce
have to be accepted. We have consensus to do that. It is my contention
that the key hierarchy attempts to address those problems that we have
already accepted into our system due to proxies so I feel the key
hierarchy is an unnecessary complexity.

  Of course I may be all wrong. If someone could just tell me exactly
what problem will completely go away by having this key hierarchy I would
greatly appreciate it. Can you tell me?

> We talked about the reasoning for the DSRK hierarchy for a long time and
> achieved consensus.  I understand that you are bringing up these
> questions again with the hop-by-hop security model in mind.

  The goalposts have moved. The discussion about the key hierarchy was
held back when we were still arguing over a 3 party protocol. That was
when disclosure of keys to people who are not the intended recipient
was a problem we were going to address. But I have come to the realization
that the working group is not interested in a protocol that could not work
in the presence of proxies and that the working group now feels that that
problem is not something that needs addressing.

  I believe that the problems that proxies introduce are the same ones that
arise when a key is shared between domains. The key hierarchy addresses the
latter but not the former. Since WG consensus is that the former is not
something that needs addressing I question why the latter needs addressing.

  A counter example would go a long way to justifying the key hierarchy.
Do you have one?

>                                                              Personally,
> I find it instructive to think about the implications of putting trust
> in proxies.  We discussed that in Vancouver and noted that billing
> inconsistencies may be the result.  If an operator is willing to handle
> those through non-protocol means (and that's what many do today), we
> should continue to allow that model of operation.

  I'm not saying we shouldn't allow that model of operation. In fact,
I am acknowledging that the WG has consensus to allow it.

  What I am saying is that by allowing that model of operation we are
agreeing to not address the problems it introduces. And that being the
case the key hierarchy becomes extraneous, an unnecessary complexity
that we should just do away with.

> best wishes for the new year,
> Lakshminath

  Thank you very much! I hope you have a great 2008.

  Dan.



--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 04 Jan 2008 17:21:28 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_00a39560-8c20-42b1-a8f7-9c046c0e0e28_"
From: Bernard Aboba <[e-mail]>
To: Hannes Tschofenig <[e-mail]>
CC: <[e-mail]>, <[e-mail]>
Subject: RE: AAA Routing with EAP-ER
Date: Fri, 4 Jan 2008 09:20:05 -0800
MIME-Version: 1.0

--_00a39560-8c20-42b1-a8f7-9c046c0e0e28_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


I think this makes the assumption that every Diameter agent advertising
support for the ERX application understands ERX.  While Diameter auth=20
servers do need to understand the application to advertise it, Diameter age=
nts=20
may only be able to forward the messages. =20
=20
This could become an issue if there is an expectation that the "local serve=
r"
will process a packet whose NAI realm is not the local realm.  Instead of
processing the packet, the Diameter agent would forward the packet to
the server corresponding to the NAI realm (e.g. the home server).=20
=20
The issue is that there is no equivalent of the "router alert" option for
AAA.=20
=20
> Date: Fri, 4 Jan 2008 11:56:35 +0100> From: [e-mail]> To=
: [e-mail]> CC: [e-mail]; [e-mail]> Su=
bject: AAA Routing with EAP-ER> > Working on> http://tools.ietf.org/wg/dime=
/draft-dondeti-dime-erp-diameter-01.txt> the question of defining AVPs vs. =
defining a new Diameter application > showed up.> > I wrote a section about=
 this into that draft and I wonder whether my > assumptions are reasonable:=
> > 3. Assumptions> > This document defines additional optional AVPs for us=
age with the> Diameter EAP application. Routing of these messages is theref=
ore> provided via the Diameter Application Identifier (among other> element=
s), as specified by the Diameter Base protocol [4]. Based on> the deploymen=
t of ERP, a local Diameter server (the same entity> serves as a Diameter pr=
oxy during the full EAP authentication) may> play the role of the ER server=
 for future re-authentication attempts.> As such, the local Diameter server=
 requesting the DSRK needs to be in> the path of the current EAP exchange b=
etween the peer and the EAP> server and also along the path in the future. =
The Diameter client is > furthermore assumed to be able to route the re-aut=
hentication > messages to the ER server.> > > Depending on some of the answ=
ers to the questions raised in this > discussion it might be necessary to d=
efine a new Diameter application > rather than just defining new AVPs.> > C=
iao> Hannes> > > [e-mail] wrote:> >> When the peer, the lo=
cal domain and the AAA-Home also> >> support ERP, a DSRK (DSRK1) may be req=
uested by the local ER server A at> >> the time of the EAP exchange.> >> > =
Some questions:> >> > 1. Is the "Local ER server" always a RADIUS client? T=
he ERX > > document seems to> > indicate that this might not always be the =
case.> >> > 2. How is the request for the DSRK made by the "local ER server=
"? > > Is the> > request authenticated with user credentials? How does the =
RADIUS server> > determine if the Request is valid?> >> > 3. How does the R=
ADIUS server know how to reach the "Local ER server"?> > The ERX document t=
alks about a "Domain Identity". How does the RADIUS > > server> > use the "=
Domain Identity" to determine what RADIUS client to send a > > packet to?> =
> Is there an assumption that the "Local ER server" is one hop away from > =
> the> > home RADIUS server? What attributes need to be placed within an > =
> Access-Accept> > to ensure that the packet is routed to the "local server=
"?> >> > 4. In Figure 1, the ERX document shows the following flow:> >> > [=
<-- EAP-Request/ ------> > Identity]> > [<-- EAP Initiate/ ------> > Reauth=
-Start]> >> > Is this a typo? The figure shows that the EAP-Request/Identit=
y isn't > > being responded> > to by the peer. If the peer implements RFC 3=
748, won't it send an > > EAP-Response,> > which will be passed to the RADI=
US server, which will then initiate > > EAP? Figure 1> > seems to show the =
EAP peer ignoring the EAP-Request, which> > implies that it needs to wait f=
or some period of time for another > > message, which> > might or might not=
 arrive. How long should it wait?> >> > If the peer doesn't respond to the =
EAP-Request/Identity, according to > > RFC 3748> > and RFC 4137, the NAS wi=
ll retransmit. So we'll have two EAP > > conversations> > going on at once?=
> >> > 5. In Figure 2, the peer is initiating what would appear to be a > >=
 standard> > RADIUS/EAP conversation via the EAP-Response/Identity. However=
, it> > would appear that the EAP Response/Identity is being "augmented" by=
> > the local server. It's hard for me to tell from the figure whether the>=
 > [DSRK Req, Domain Identity] is being inserted within the > > EAP-Respons=
e/Identity,> > or whether it represents separate RADIUS attributes. Can you=
 clarify?> >> > 6. If the "local 'server" isn't on the path between the NAS=
 and the > > home server> > (as it might not be, because of failover), what=
 happens? Does each > > proxy> > also need to host a "local server" to make=
 sure that doesn't occur?> > If the "local server" is not on the path, then=
 it seems like two > > distinct messages> > would be required. Is there an =
expectation that the RADIUS > > Access-Accept> > will be multicast, or that=
 two distinct RADIUS Access-Accept packets will> > be sent?> >> >> >> >> >>=
 >> > -- > > to unsubscribe send a message to [e-mail]=
g with> > the word 'unsubscribe' in a single line as the message text body.=
> > archive: <http://psg.com/lists/radiusext/>> =

--_00a39560-8c20-42b1-a8f7-9c046c0e0e28_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
I think this makes&nbsp;the assumption that every Diameter agent advertisin=
g<BR>
support for the ERX application understands ERX.&nbsp; While Diameter auth =
<BR>
servers do need to understand the application to advertise it, Diameter age=
nts <BR>
may only be able to forward the messages.&nbsp; <BR>
&nbsp;<BR>
This could become an issue if there is an expectation that the "local serve=
r"<BR>
will process a packet whose NAI realm is not the local realm.&nbsp; Instead=
 of<BR>
processing the packet, the Diameter agent would forward the packet to<BR>
the server corresponding to the NAI realm (e.g. the home server). <BR>
&nbsp;<BR>
The issue is that there is no equivalent of the "router alert" option for<B=
R>
AAA. <BR>
&nbsp;<BR>
<BR><BR>&gt; Date: Fri, 4 Jan 2008 11:56:35 +0100<BR>&gt; From: Hannes.Tsch=
[e-mail]<BR>&gt; To: [e-mail]<BR>&gt; CC: radiusext@=
ops.ietf.org; [e-mail]<BR>&gt; Subject: AAA Routing with EAP-ER<BR>&g=
t; <BR>&gt; Working on<BR>&gt; http://tools.ietf.org/wg/dime/draft-dondeti-=
dime-erp-diameter-01.txt<BR>&gt; the question of defining AVPs vs. defining=
 a new Diameter application <BR>&gt; showed up.<BR>&gt; <BR>&gt; I wrote a =
section about this into that draft and I wonder whether my <BR>&gt; assumpt=
ions are reasonable:<BR>&gt; <BR>&gt; 3. Assumptions<BR>&gt; <BR>&gt; This =
document defines additional optional AVPs for usage with the<BR>&gt; Diamet=
er EAP application. Routing of these messages is therefore<BR>&gt; provided=
 via the Diameter Application Identifier (among other<BR>&gt; elements), as=
 specified by the Diameter Base protocol [4]. Based on<BR>&gt; the deployme=
nt of ERP, a local Diameter server (the same entity<BR>&gt; serves as a Dia=
meter proxy during the full EAP authentication) may<BR>&gt; play the role o=
f the ER server for future re-authentication attempts.<BR>&gt; As such, the=
 local Diameter server requesting the DSRK needs to be in<BR>&gt; the path =
of the current EAP exchange between the peer and the EAP<BR>&gt; server and=
 also along the path in the future. The Diameter client is <BR>&gt; further=
more assumed to be able to route the re-authentication <BR>&gt; messages to=
 the ER server.<BR>&gt; <BR>&gt; <BR>&gt; Depending on some of the answers =
to the questions raised in this <BR>&gt; discussion it might be necessary t=
o define a new Diameter application <BR>&gt; rather than just defining new =
AVPs.<BR>&gt; <BR>&gt; Ciao<BR>&gt; Hannes<BR>&gt; <BR>&gt; <BR>&gt; Bernar=
[e-mail] wrote:<BR>&gt; &gt;&gt; When the peer, the local domain=
 and the AAA-Home also<BR>&gt; &gt;&gt; support ERP, a DSRK (DSRK1) may be =
requested by the local ER server A at<BR>&gt; &gt;&gt; the time of the EAP =
exchange.<BR>&gt; &gt;<BR>&gt; &gt; Some questions:<BR>&gt; &gt;<BR>&gt; &g=
t; 1. Is the "Local ER server" always a RADIUS client? The ERX <BR>&gt; &gt=
; document seems to<BR>&gt; &gt; indicate that this might not always be the=
 case.<BR>&gt; &gt;<BR>&gt; &gt; 2. How is the request for the DSRK made by=
 the "local ER server"? <BR>&gt; &gt; Is the<BR>&gt; &gt; request authentic=
ated with user credentials? How does the RADIUS server<BR>&gt; &gt; determi=
ne if the Request is valid?<BR>&gt; &gt;<BR>&gt; &gt; 3. How does the RADIU=
S server know how to reach the "Local ER server"?<BR>&gt; &gt; The ERX docu=
ment talks about a "Domain Identity". How does the RADIUS <BR>&gt; &gt; ser=
ver<BR>&gt; &gt; use the "Domain Identity" to determine what RADIUS client =
to send a <BR>&gt; &gt; packet to?<BR>&gt; &gt; Is there an assumption that=
 the "Local ER server" is one hop away from <BR>&gt; &gt; the<BR>&gt; &gt; =
home RADIUS server? What attributes need to be placed within an <BR>&gt; &g=
t; Access-Accept<BR>&gt; &gt; to ensure that the packet is routed to the "l=
ocal server"?<BR>&gt; &gt;<BR>&gt; &gt; 4. In Figure 1, the ERX document sh=
ows the following flow:<BR>&gt; &gt;<BR>&gt; &gt; [&lt;-- EAP-Request/ ----=
--<BR>&gt; &gt; Identity]<BR>&gt; &gt; [&lt;-- EAP Initiate/ ------<BR>&gt;=
 &gt; Reauth-Start]<BR>&gt; &gt;<BR>&gt; &gt; Is this a typo? The figure sh=
ows that the EAP-Request/Identity isn't <BR>&gt; &gt; being responded<BR>&g=
t; &gt; to by the peer. If the peer implements RFC 3748, won't it send an <=
BR>&gt; &gt; EAP-Response,<BR>&gt; &gt; which will be passed to the RADIUS =
server, which will then initiate <BR>&gt; &gt; EAP? Figure 1<BR>&gt; &gt; s=
eems to show the EAP peer ignoring the EAP-Request, which<BR>&gt; &gt; impl=
ies that it needs to wait for some period of time for another <BR>&gt; &gt;=
 message, which<BR>&gt; &gt; might or might not arrive. How long should it =
wait?<BR>&gt; &gt;<BR>&gt; &gt; If the peer doesn't respond to the EAP-Requ=
est/Identity, according to <BR>&gt; &gt; RFC 3748<BR>&gt; &gt; and RFC 4137=
, the NAS will retransmit. So we'll have two EAP <BR>&gt; &gt; conversation=
s<BR>&gt; &gt; going on at once?<BR>&gt; &gt;<BR>&gt; &gt; 5. In Figure 2, =
the peer is initiating what would appear to be a <BR>&gt; &gt; standard<BR>=
&gt; &gt; RADIUS/EAP conversation via the EAP-Response/Identity. However, i=
t<BR>&gt; &gt; would appear that the EAP Response/Identity is being "augmen=
ted" by<BR>&gt; &gt; the local server. It's hard for me to tell from the fi=
gure whether the<BR>&gt; &gt; [DSRK Req, Domain Identity] is being inserted=
 within the <BR>&gt; &gt; EAP-Response/Identity,<BR>&gt; &gt; or whether it=
 represents separate RADIUS attributes. Can you clarify?<BR>&gt; &gt;<BR>&g=
t; &gt; 6. If the "local 'server" isn't on the path between the NAS and the=
 <BR>&gt; &gt; home server<BR>&gt; &gt; (as it might not be, because of fai=
lover), what happens? Does each <BR>&gt; &gt; proxy<BR>&gt; &gt; also need =
to host a "local server" to make sure that doesn't occur?<BR>&gt; &gt; If t=
he "local server" is not on the path, then it seems like two <BR>&gt; &gt; =
distinct messages<BR>&gt; &gt; would be required. Is there an expectation t=
hat the RADIUS <BR>&gt; &gt; Access-Accept<BR>&gt; &gt; will be multicast, =
or that two distinct RADIUS Access-Accept packets will<BR>&gt; &gt; be sent=
?<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; =
&gt;<BR>&gt; &gt; -- <BR>&gt; &gt; to unsubscribe send a message to radiuse=
[e-mail] with<BR>&gt; &gt; the word 'unsubscribe' in a singl=
e line as the message text body.<BR>&gt; &gt; archive: &lt;http://psg.com/l=
ists/radiusext/&gt;<BR>&gt; <BR><BR></body>
</html>=

--_00a39560-8c20-42b1-a8f7-9c046c0e0e28_--

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 04 Jan 2008 16:30:16 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_c0b33f73-2591-4583-8e87-623f89c426aa_"
From: Bernard Aboba <[e-mail]>
To: Dan Harkins <[e-mail]>
CC: radext mailing list <[e-mail]>, <[e-mail]>
Subject: RE: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
Date: Fri, 4 Jan 2008 08:29:53 -0800
MIME-Version: 1.0

--_c0b33f73-2591-4583-8e87-623f89c426aa_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


> You could only end up with the same rMSK being used for multiple NASs> if=
 the sequence number the peer used during re-auth was the same. So if> that=
 is deemed a problem then mandate that the sequence number be a> monotonica=
lly increasing counter which is initialized to 1 when the peer> finishes in=
itial and full EAP authentication and not when a new rRK is> derived. No ne=
ed for any domain differentiation at any level, just a> simple edit of half=
 a sentence in the ERX document.> > If this is the only problem that is sol=
ved by having this key hierarchy> then let's do the simple edit I propose a=
nd get rid of the key hierarchy!> Agreed?
=20
My understanding is that this scheme is in use today, requiring only the MS=
K,
and no changes to the AAA server or new RADIUS attributes.  Only changes to
the peer, authenticator and local server are needed.  As I understand it, t=
he=20
AAA server only sees Access-Requests originating from the "local server"=20
(e.g. NAS-Identifier =3D local server), so it just responds with the MSK.=20
However, the peer and authenticator do need to be modified to=20
negotiate the scheme prior to first use, since the rMSK is now a function=20
of the MSK and the counter, so as to ensure that no authenticators=20
share the same keying material. =20
=20
=20
 =

--_c0b33f73-2591-4583-8e87-623f89c426aa_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
&gt; You could only end up with the same rMSK being used for multiple NASs<=
BR>&gt; if the sequence number the peer used during re-auth was the same. S=
o if<BR>&gt; that is deemed a problem then mandate that the sequence number=
 be a<BR>&gt; monotonically increasing counter which is initialized to 1 wh=
en the peer<BR>&gt; finishes initial and full EAP authentication and not wh=
en a new rRK is<BR>&gt; derived. No need for any domain differentiation at =
any level, just a<BR>&gt; simple edit of half a sentence in the ERX documen=
t.<BR>&gt; <BR>&gt; If this is the only problem that is solved by having th=
is key hierarchy<BR>&gt; then let's do the simple edit I propose and get ri=
d of the key hierarchy!<BR>&gt; Agreed?<BR>
&nbsp;<BR>
My understanding is that this scheme is in use today, requiring only the MS=
K,<BR>
and no changes to the AAA server or new RADIUS attributes.&nbsp; Only chang=
es to<BR>
the peer, authenticator and local server are needed.&nbsp; As I understand =
it, the <BR>
AAA server only sees Access-Requests originating from the "local server" <B=
R>
(e.g. NAS-Identifier =3D local server), so&nbsp;it just responds with the M=
SK. <BR>
However, the peer&nbsp;and authenticator do&nbsp;need to be modified to <BR=
>
negotiate the scheme prior to&nbsp;first&nbsp;use, since the rMSK is now a =
function <BR>
of the MSK and the counter, so as to ensure that no authenticators <BR>
share the same keying material.&nbsp; <BR>
&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR></body>
</html>=

--_c0b33f73-2591-4583-8e87-623f89c426aa_--

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 04 Jan 2008 16:12:11 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Alan DeKok'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: E2E and crypto-agility
Date: Fri, 4 Jan 2008 08:10:52 -0800
Message-ID: <005801c84eec$61eed6b0$25cc8410$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: AchOqDT0w9muuIosTgKzNKbZ3TIilgAQ3CxQ
Content-Language: en-us

Glen Zorn wrote:
> The only purpose of which I'm aware for e2e encryption in RADIUS is the
> hiding of the encrypted things from proxies.

  I trust the people I work with enough to leave my car keys out in
public.  But I don't hand them the keys and say "go ahead, take it."

  For me, e2e encryption in RADIUS is about *increasing* the security,
not *perfecting* it.  The proxies have no business knowing the keys, so
e2e encryption helps increase security.

  If the proxies collude with the local network, then they can gain
information that negates e2e encryption... because they effectively
become one of the "ends" in "end-to-end".
[gwz] 
No collusion is required, just a hack combined with sniffing the wireless:
barely more effort than w/o this stuff...
[/gwz]

  I see no problem here.  e2e encryption is useful, and there are
multiple methods where this can be done to *improve* security without
making it perfect.
[gwz] 
If that is your goal, I'd suggest trying to find a method that doesn't
involve modifying every L2 in the world...
[/gwz]

  Alan DeKok.


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 04 Jan 2008 15:56:55 +0000
Message-ID: <[e-mail]>
Date: Fri, 4 Jan 2008 07:55:06 -0800 (PST)
Subject: RE: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
From: "Dan Harkins" <[e-mail]>
To: "Narayanan, Vidya" <[e-mail]>
Cc: "Dan Harkins" <[e-mail]>, "Alan DeKok" <[e-mail]>, "radext mailing list" <[e-mail]>, [e-mail]
User-Agent: SquirrelMail/1.4.8
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit

  Hi Vidya,

  Thank you very much for responding.

On Thu, January 3, 2008 10:20 pm, Narayanan, Vidya wrote:
> Hi Dan,
> There are two points here.  End-to-end protection of key material is
> certainly feasible and is not prohibited by the model - it is quite
> feasible in the enterprise space, for instance.  Even when hop-by-hop
> protected, the proxies don't have authorization to use the DSRK.  It is
> only meant for use by the local ER server.

  I understand that it is "not prohibited" but it is not mandatory and
therefore when looking at the security of the scheme we have to operate
under the assumption that the key is being exposed to parties that are
the intended recipient.

  This non-authorization isn't enforced anyway is it? It is merely by
fiat in the document that the proxies are not authorized to use the key.
We're just assuming that they won't misbehave.

> For key separation, it is important to have different DSRKs per domain.
> For instance, there must be separation between the rMSKs given to the
> different NASs - if the same DSRK was given to multiple local ER
> servers, you would end up with the same rMSK for multiple NASs.  We
> could come up with other key separation techniques that keep the rMSK
> unique, but that would mean introducing the domain or an equivalent
> differentiation at that level instead of at the DSRK.

  You could only end up with the same rMSK being used for multiple NASs
if the sequence number the peer used during re-auth was the same. So if
that is deemed a problem then mandate that the sequence number be a
monotonically increasing counter which is initialized to 1 when the peer
finishes initial and full EAP authentication and not when a new rRK is
derived. No need for any domain differentiation at any level, just a
simple edit of half a sentence in the ERX document.

  If this is the only problem that is solved by having this key hierarchy
then let's do the simple edit I propose and get rid of the key hierarchy!
Agreed?

> Also, another point is that Domain A and Domain B may actually be
> different administrative domains, in which case, it is not necessarily
> true that they have a business relationship with each other or that they
> have the same level of relationship with the home domain.  So, there is
> no assumption that any one visited domain is a proxy in the path between
> another visited domain and the home domain.  Hence, ensuring proper key
> separation at the DSRK level is important.

  Yes, Domain A and Domain B may actually be different administrative
domains! And the proxies between them and the home server might be too!
And they all might have different business relationships with each other!
That's my point!

  We're just placing blind trust in proxies to "do the right thing".
That being the case the level of blind trust placed in ER servers in
Domain A or Domain B CANNOT be any less than the level of blind trust
placed in proxies between them and the home AAA server.

  Again, what _specific problem_ is being solved by having different keys
in Domain A and Domain B? Do you want to stop NASs in Domain A from
impersonating NASs in Domain B but for some reason you're not concerned
about proxies impersonating Domain A or Domain B in their entirety?

  It seems to me that any problem that requires different keys for ER
Servers in Domain A and Domain B will also require different keys for all
proxies. But we can't do that so we can't really use key separation to
solve the problem, whatever it is.

  Key separation would be important if there was a 3 party protocol between
the home AAA server the ER server and the peer that disclosed a unique
key to the ER server and only the ER server. But there isn't.

  The argument against a 3 party protocol is that the peer doesn't care
to whom the key is disclosed as long as he continues to get service
provided (and there's no surprises in the bill at the end of the month
but that's what legal documents are for). If the network has to disclose
keys to unintended recipients in order to continue to be able to provide
service then have at it, disclose keys!

  What we've ended up with is a network being trusted implicitly to not
misbehave with keys it obtains and a peer that doesn't care as long as
he gets a dial tone. So please tell me what problem is being solved by
having this key hierarchy.

  Thank you again for responding to my post and I would be very grateful
if you could answer my questions above and/or point out the errors in
my logic.

  regards,

  Dan.

> Regards,
> Vidya
>
>> -----Original Message-----
>> From: Dan Harkins [mailto:[e-mail]]
>> Sent: Thursday, January 03, 2008 4:33 PM
>> To: Narayanan, Vidya
>> Cc: Alan DeKok; radext mailing list; [e-mail]
>> Subject: RE: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
>>
>>
>>   Hi Vidya,
>>
>>   There may be proxies in between AAA-Home and Local ER
>> server A and between AAA-Home and Local ER Server B. There is
>> strong consensus in the group that there is no problem with
>> this that all the proxies will behave themselves and not
>> abuse the fact that they know DRSK1 and/or DRSK2. That being
>> the case why cannot the same logic that justifies these
>> proxies having such keying material be used to just give the
>> same key to Local ER Server A and Local ER Server B? Why do
>> we need to have different DRSKs? What problem are you trying
>> to solve and isn't that problem still going to be there since
>> proxies are now involved?
>>
>>   Dan.
>>
>> On Thu, January 3, 2008 3:02 pm, Narayanan, Vidya wrote:
>> > Hi Alan,
>> > Some of this is revisiting the HOKEY charter discussions and can be
>> > found in the archives, but let me try a bit further to clarify here.
>> >
>> > Consider the following figure:
>> >
>> >                                    -----------
>> >                                   | AAA-Home  |
>> >                                    -----------
>> >                                         |
>> >
>> ------------------------------------------------------
>> >                |
>>           |
>> >        -------------------
>> > -------------------
>> >       | Local ER server A |
>> | Local ER
>> > server B |
>> >       |    (Domain A)     |
>> |    (Domain
>> > B)     |
>> >        -------------------
>> > -------------------
>> >                |
>>           |
>> >           --------------
>> > --------------
>> >          |              |                                       |
>> > |
>> >      --------        --------
>>  --------
>> > --------
>> >     | NAS A1 |      | NAS A2 |
>> | NAS B1 |
>> > | NAS B2 |
>> >      --------        --------
>>  --------
>> > --------
>> >
>> >     ------
>> >    | Peer |  ---------->
>> >     ------
>> >
>> >
>> > In the figure above, the peer is attached to a NAS (say,
>> A1) in Domain
>> > A, while its home domain corresponds to AAA-Home" which is
>> potentially
>> > much further away than Domain A is.  The first time around,
>> the peer
>> > authenticates with its home AAA server, which results in an
>> MSK at NAS
>> > A1 and an EMSK at AAA-Home.  This is in accordance with regular EAP
>> > operation.  When the peer, the local domain and the AAA-Home also
>> > support ERP, a DSRK (DSRK1) may be requested by the local
>> ER server A
>> > at the time of the EAP exchange.  DSRK1 is derived from the
>> EMSK and
>> > given to the Local ER Server A.  Now, when the peer moves
>> from NAS A1
>> > to NAS A2, it only needs to perform an ERP exchange with
>> the Local ER Server A.
>> > No exchange is required with AAA-Home.  This finishes much quicker
>> > than an exchange that would have to go all the way to AAA-Home.
>> >
>> > It is when the peer moves from Domain A to Domain B that
>> the peer has
>> > to talk to AAA-Home again.  At this point, a DSRK2 may be given to
>> > Local ER Server B, which then gets used for
>> re-authentication within
>> > that domain (say, when the peer moves from NAS B1 to NAS B2).
>> >
>> > As shown, all re-authentications within a local domain are
>> restricted
>> > to that domain with no exchanges needed with the home
>> domain (unless
>> > the DSRK expired).  Exchanges involve the home domain when the peer
>> > crosses domain boundaries.
>> >
>> > Hope this helps.
>> >
>> > Thanks,
>> > Vidya
>> >
>> >> -----Original Message-----
>> >> From: Alan DeKok [mailto:[e-mail]]
>> >> Sent: Thursday, January 03, 2008 2:01 PM
>> >> To: Narayanan, Vidya
>> >> Cc: [e-mail]; 'radext mailing list'
>> >> Subject: Re: [HOKEY] Review of
>> draft-gaonkar-radext-erp-attrs-02.txt
>> >>
>> >> Narayanan, Vidya wrote:
>> >> > Thanks for the review.  Let me attempt to clarify a few
>> things that
>> >> > may answer majority of your questions below.  The DSRK
>> is a domain
>> >> > specific root key that is derived from the EMSK for the
>> purpose of
>> >> > having a local EAP Re-authentication server (ER server) in
>> >> the visited domain.
>> >>
>> >>   I'm not sure I understand why.  If there isn't an EAP
>> >> re-authentication server, then the EAP authentications will go
>> >> through the local AAA server.  So there is significant benefit in
>> >> *always* going through the local AAA server.  i.e.
>> >> having the AAA servers cache the keys required for
>> re-authentication.
>> >>
>> >> > "Visited domain" doesn't necessarily imply administrative
>> >> in this case
>> >> > - a large domain can be broken up into multiple smaller
>> domains for
>> >> > sake of efficient re-authentication.
>> >>
>> >>   I'm not sure I understand how this helps efficiency.  If there's
>> >> one large domain for the initial authentication, then only
>> one domain
>> >> is needed.  If the home server can handle the
>> re-authentication, then
>> >> there's doubly no need for multiple domains.
>> >>
>> >> > This is done so that the latency involved in
>> >> reauthentication at the
>> >> > time of a handoff for a peer is minimal (the peer doesn't
>> >> have to go
>> >> > back to the home AAA server to get reauthenticated).
>> When the peer
>> >> > hands off across domains (i.e., leaves the boundary of an
>> >> ER server),
>> >> > it needs to communicate with the home AAA server to obtain
>> >> a new DSRK
>> >> > for the new ER server.  This may be done using a full EAP
>> >> exchange or
>> >> > with an ER exchange with the home AAA server.
>> >>
>> >>   If the re-authentication has to go back to the home AAA
>> server for
>> >> a to obtain a new DSRK, why are there multiple domains?  The home
>> >> server is manifestly capable of handling all re-authentication
>> >> requests.
>> >>
>> >> > The problem statement and use cases are described further in
>> >> >
>> >>
>> http://www.ietf.org/internet-drafts/draft-ietf-hokey-reauth-ps-07.txt.
>> >> > The ERX protocol draft itself describes the protocol in detail -
>> >> >
>> >>
>> http://www.ietf.org/internet-drafts/draft-ietf-hokey-reauth-ps-07.txt
>> >> > - figure 2, for instance, shows the recipient of the DSRK
>> >> and how it
>> >> > is further used for reauthentication during
>> authenticator changes
>> >> > within that domain.
>> >>
>> >>   I think I need to address many of my comments to that draft.
>> >>
>> >> > Hope this clarifies many of the things you ask below.  A
>> >> few further
>> >> > comments inline on the other questions.
>> >>
>> >>   It clarifies it a little.  I've gone over the problem statement
>> >> draft, and have some questions about it.
>> >>
>> >> > Actually, this document has gone through a couple of
>> >> contortions due
>> >> > to lack of clarity from the RADIUS side on how to proceed here.
>> >>
>> >>   The radext WG is always available to answer questions.
>> >> I've been lurking on hokey for a while, but until recently
>> have been
>> >> too busy to pay much attention to the drafts.
>> >>
>> >> > There will only be one key response, but the key name is
>> >> still needed
>> >> > so that the peer, upon reauthentication later, can refer
>> to the key.
>> >>
>> >>   Ok... I have questions, but I'll address them to another
>> draft, I
>> >> think.
>> >>
>> >> > As I mentioned before, there is no goal to change the
>> >> RADIUS security
>> >> > measures.  This draft will also be updated to work with
>> keywrap and
>> >> > DTLS
>> >>
>> >>   I don't believe either method is strictly necessary for
>> >> transporting these keys.  There are alternatives that
>> should be able
>> >> to work.
>> >>
>> >>   Alan DeKok.
>> >>
>> >
>> > _______________________________________________
>> > HOKEY mailing list
>> > [e-mail]
>> > https://www1.ietf.org/mailman/listinfo/hokey
>> >
>>
>>
>>
>



--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 04 Jan 2008 10:57:58 +0000
Message-ID: <[e-mail]>
Date: Fri, 04 Jan 2008 11:56:35 +0100
From: Hannes Tschofenig <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: AAA Routing with EAP-ER
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Working on
http://tools.ietf.org/wg/dime/draft-dondeti-dime-erp-diameter-01.txt
the question of defining AVPs vs. defining a new Diameter application 
showed up.

I wrote a section about this into that draft and I wonder whether my 
assumptions are reasonable:

3.  Assumptions

   This document defines additional optional AVPs for usage with the
   Diameter EAP application.  Routing of these messages is therefore
   provided via the Diameter Application Identifier (among other
   elements), as specified by the Diameter Base protocol [4].  Based on
   the deployment of ERP, a local Diameter server (the same entity
   serves as a Diameter proxy during the full EAP authentication) may
   play the role of the ER server for future re-authentication attempts.
   As such, the local Diameter server requesting the DSRK needs to be in
   the path of the current EAP exchange between the peer and the EAP
   server and also along the path in the future.  The Diameter client is 
   furthermore assumed to be able to route the re-authentication 
   messages to the ER server.


Depending on some of the answers to the questions raised in this 
discussion it might be necessary to define a new Diameter application 
rather than just defining new AVPs.

Ciao
Hannes


[e-mail] wrote:
>> When the peer, the local domain and the AAA-Home also
>> support ERP, a DSRK (DSRK1) may be requested by the local ER server A at
>> the time of the EAP exchange.
>
> Some questions:
>
> 1. Is the  "Local ER server" always a RADIUS client?   The ERX 
> document seems to
> indicate that this might not always be the case.
>
> 2.  How is the request for the DSRK made by the "local ER server"?    
> Is the
> request authenticated with user credentials?  How does the RADIUS server
> determine if the Request is valid?
>
> 3. How does the RADIUS server know how to reach the "Local ER server"?
> The ERX document talks about a "Domain Identity".  How does the RADIUS 
> server
> use the "Domain Identity" to determine what RADIUS client to send a 
> packet to?
> Is there an assumption that the "Local ER server" is one hop away from 
> the
> home RADIUS server?  What attributes need to be placed within an 
> Access-Accept
> to ensure that the packet is routed to the "local server"?
>
> 4.  In Figure 1, the ERX document shows the following flow:
>
>    [<-- EAP-Request/ ------
>        Identity]
>    [<-- EAP Initiate/ ------
>        Reauth-Start]
>
> Is this a typo?  The figure shows that the EAP-Request/Identity isn't 
> being responded
> to by the peer.  If the peer implements RFC 3748, won't it send an 
> EAP-Response,
> which will be passed to the RADIUS server, which will then initiate 
> EAP? Figure 1
> seems to show the EAP peer ignoring the EAP-Request, which
> implies that it needs to wait for some period of time for another 
> message, which
> might or might not arrive.   How long should it wait?
>
> If the peer doesn't respond to the EAP-Request/Identity, according to 
> RFC 3748
> and RFC 4137, the NAS will retransmit.  So we'll have two EAP 
> conversations
> going on at once?
>
> 5. In Figure 2,  the peer is initiating what would appear to be a 
> standard
> RADIUS/EAP conversation via the EAP-Response/Identity.   However, it
> would appear that the EAP Response/Identity is being "augmented" by
> the local server.  It's hard for me to tell from the figure whether the
> [DSRK Req, Domain Identity] is being inserted within the 
> EAP-Response/Identity,
> or whether it represents separate RADIUS attributes.  Can you clarify?
>
> 6. If the "local 'server" isn't on the path between the NAS and the 
> home server
> (as it might not be, because of failover), what happens?   Does each 
> proxy
> also need to host a "local server" to make sure that doesn't occur?
> If the "local server" is not on the path, then it seems like two 
> distinct messages
> would be required.   Is there an expectation that the RADIUS 
> Access-Accept
> will be multicast, or that two distinct RADIUS Access-Accept packets will
> be sent?
>
>
>
>
>
>
> -- 
> to unsubscribe send a message to [e-mail] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 04 Jan 2008 09:37:35 +0000
Message-ID: <[e-mail]>
Date: Fri, 04 Jan 2008 10:35:14 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: [e-mail]
CC: Glen Zorn <[e-mail]>, [e-mail]
Subject: Re: E2E and crypto-agility
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

[e-mail] wrote:
> The question that is before the WG is "is support for e2e encryption a
> requirement for RADIUS crypto-agility?"

  If the IESG mandates it, yes.  Otherwise, I don't see a need for it.

> I think that this question is related to the automated key management
> question, because if we say that it is a requirement, then we have an
> n x n problem that would seem to fall into the RFC 4107 requirements
> for automated key management.

  Yes.

  Alan DeKok.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 04 Jan 2008 08:56:14 +0000
Message-ID: <[e-mail]>
From: <[e-mail]>
To: <[e-mail]>
Subject: Re: E2E and crypto-agility
Date: Fri, 4 Jan 2008 00:55:35 -0800
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

> Is there a *real-world* problem we're trying
> to solve here, or a theoretical exercise that is made moot by real-world
> business realities?

I think there may be a problem here, but I'm not clear how that problem
is related to "RADIUS crypto-agility" or why it is in the interest of the
RADEXT WG to try to solve it at the present moment. 

For example, using crypto-agility, ciphersuites can be negotiated to 
provide improved integrity protection as well as confidentiality for
a portion or all of the RADIUS packet. 

This would seem to be an orthogonal question to the topology of
RADIUS clients, proxies and servers.  

Or am I missing something? 

Yes, automated key management, if implemented, might make it
possible for untrusted proxies to be bypassed (e.g. the local
proxy might be able to bypass a less trust worthy proxy and
talk to an entity closer to the home server,  assuming that the 
two entities share trust anchors).

And yes, it is possible that somewhere, somehow, someone
might want to implement Kerb/RADIUS or CMS (which were
discussed in AAA WG years ago but which languished for lack of interest). 

However, to me this doesn't seem like a requirement 
in the development of the two proposals that we've been
discussing.    

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 04 Jan 2008 08:19:27 +0000
Message-ID: <[e-mail]>
From: <[e-mail]>
To: "Alan DeKok" <[e-mail]>, "Glen Zorn" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: E2E and crypto-agility
Date: Fri, 4 Jan 2008 00:19:11 -0800
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

>  I see no problem here.  e2e encryption is useful, and there are
> multiple methods where this can be done to *improve* security without
> making it perfect.

The question that is before the WG is "is support for e2e encryption a 
requirement for RADIUS crypto-agility?"

I think that this question is related to the automated key management 
question, because if we say that it is a requirement, then we have an
n x n problem that would seem to fall into the RFC 4107 requirements
for automated key management. 

 

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 04 Jan 2008 08:10:49 +0000
Message-ID: <[e-mail]>
From: <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
Date: Fri, 4 Jan 2008 00:10:35 -0800
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

>When the peer, the local domain and the AAA-Home also
> support ERP, a DSRK (DSRK1) may be requested by the local ER server A at
> the time of the EAP exchange.

Some questions:

1. Is the  "Local ER server" always a RADIUS client?   The ERX document 
seems to
indicate that this might not always be the case.

2.  How is the request for the DSRK made by the "local ER server"?    Is the
request authenticated with user credentials?  How does the RADIUS server
determine if the Request is valid?

3. How does the RADIUS server know how to reach the "Local ER server"?
The ERX document talks about a "Domain Identity".  How does the RADIUS 
server
use the "Domain Identity" to determine what RADIUS client to send a packet 
to?
Is there an assumption that the "Local ER server" is one hop away from the
home RADIUS server?  What attributes need to be placed within an 
Access-Accept
to ensure that the packet is routed to the "local server"?

4.  In Figure 1, the ERX document shows the following flow:

    [<-- EAP-Request/ ------
        Identity]
    [<-- EAP Initiate/ ------
        Reauth-Start]

Is this a typo?  The figure shows that the EAP-Request/Identity isn't being 
responded
to by the peer.  If the peer implements RFC 3748, won't it send an 
EAP-Response,
which will be passed to the RADIUS server, which will then initiate EAP? 
Figure 1
seems to show the EAP peer ignoring the EAP-Request, which
implies that it needs to wait for some period of time for another message, 
which
might or might not arrive.   How long should it wait?

If the peer doesn't respond to the EAP-Request/Identity, according to RFC 
3748
and RFC 4137, the NAS will retransmit.  So we'll have two EAP conversations
going on at once?

5. In Figure 2,  the peer is initiating what would appear to be a standard
RADIUS/EAP conversation via the EAP-Response/Identity.   However, it
would appear that the EAP Response/Identity is being "augmented" by
the local server.  It's hard for me to tell from the figure whether the
[DSRK Req, Domain Identity] is being inserted within the 
EAP-Response/Identity,
or whether it represents separate RADIUS attributes.  Can you clarify?

6. If the "local 'server" isn't on the path between the NAS and the home 
server
(as it might not be, because of failover), what happens?   Does each proxy
also need to host a "local server" to make sure that doesn't occur?
If the "local server" is not on the path, then it seems like two distinct 
messages
would be required.   Is there an expectation that the RADIUS Access-Accept
will be multicast, or that two distinct RADIUS Access-Accept packets will
be sent?



 


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 04 Jan 2008 08:03:22 +0000
Message-ID: <[e-mail]>
Date: Fri, 04 Jan 2008 09:01:05 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Glen Zorn <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: E2E and crypto-agility
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:
> The only purpose of which I'm aware for e2e encryption in RADIUS is the
> hiding of the encrypted things from proxies.

  I trust the people I work with enough to leave my car keys out in
public.  But I don't hand them the keys and say "go ahead, take it."

  For me, e2e encryption in RADIUS is about *increasing* the security,
not *perfecting* it.  The proxies have no business knowing the keys, so
e2e encryption helps increase security.

  If the proxies collude with the local network, then they can gain
information that negates e2e encryption... because they effectively
become one of the "ends" in "end-to-end".

  I see no problem here.  e2e encryption is useful, and there are
multiple methods where this can be done to *improve* security without
making it perfect.

  Alan DeKok.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 04 Jan 2008 07:30:16 +0000
From: Stefan Winter <[e-mail]>
Organization: Fondation RESTENA
To: [e-mail]
Subject: Re: Comments on "practical deployments"
Date: Fri, 4 Jan 2008 08:29:01 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
Cc: "David B. Nelson" <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2960769.TSQmb884QQ"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>

--nextPart2960769.TSQmb884QQ
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Am Donnerstag, 27. Dezember 2007 19:35:02 schrieb Alan DeKok:
> David B. Nelson wrote:
> >>   If the only way to obtain network access is via EAP, then you have a
> >> bootstrapping problem.  Once the users have signed up, everything is
> >> great.  The users who *haven't* signed up are shut out.  Permanently.
> >
> > So, this is really an enrollment issue, not an authentication issue?
>
>   No.  Think of roaming, which I've been spending a lot of time on lately.
>
>   If authentication is required for any IP-based network access, then
> how do roaming users know that they can authenticate using the local
> network?  Pre-provisioning devices with roaming knowledge doesn't scale,
> and it doesn't handle dynamic networks.  802.11af doesn't scale either,
> and isn't designed to scale.
>
>   When the user doesn't have any network access, they can't determine
> whether or not authentication is possible.  They can't determine which
> authentication credentials to use.  So requiring authentication means
> *forbidding* network access to a large class of users who could
> *potentially* obtain network access.
>
>   Alan DeKok.
>
> --
> to unsubscribe send a message to [e-mail] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>



=2D-=20
Stefan WINTER

Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale e=
t de=20
la Recherche
Ingenieur Forschung & Entwicklung

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
E-Mail: [e-mail] =A0 =A0 Tel.:  =A0 =A0+352 424409-1
http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0  =A0 Fax: =A0 =A0 =A0+352 422=
473

--nextPart2960769.TSQmb884QQ
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)

iD8DBQBHfeA9+jm90f8eFWYRAtsiAKCCJMZ86n4c9ydfB5KbsOp2C3wmdgCePiGJ
TpoeP1ijAdszdC4xngz6ns8=
=xWyp
-----END PGP SIGNATURE-----

--nextPart2960769.TSQmb884QQ--

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 04 Jan 2008 07:23:26 +0000
From: Stefan Winter <[e-mail]>
Organization: Fondation RESTENA
To: Alan DeKok <[e-mail]>, Bernard Aboba <[e-mail]>, [e-mail]
Subject: Re: Comments on "practical deployments"
Date: Fri, 4 Jan 2008 08:22:17 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3738705.siFGThUpKB"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>

--nextPart3738705.siFGThUpKB
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

> > It will be interesting to see how well it works.  I have previously been
> > involved in a number of
> > inter-domain roaming trials.  When the RADIUS traffic was routed through
> > an exchange point,
> > the results were not very promising.  With packet loss rates of 1-5%,
>
>   I'll track the tests, and see if we can do some measurements under load.
>
>   For existing (non-EAP) proxies, I don't recall seeing loss rates that
> high.  I'll go check, but I think latencies and loss have decreased,
> while bandwidth has increased in the net.  Plus, most RADIUS
> interconnects are now done over Ipsec, which helps with the underlying
> reliability.

This is why we dug out RadSec. The network backbone we are using typically=
=20
performs a lot better than 1-5% losses, but still the number of packets=20
involved in an EAP auth almost cries for a reliable transport.

IPSec was deployed (maybe still is, I can try to find out), but according t=
o=20
the admin there it was a real pain in the ... various parts of the body.

Greetings,

Stefan Winter

=2D-=20

Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale e=
t de=20
la Recherche
Ingenieur Forschung & Entwicklung

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
E-Mail: [e-mail] =A0 =A0 Tel.:  =A0 =A0+352 424409-1
http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0  =A0 Fax: =A0 =A0 =A0+352 422=
473

--nextPart3738705.siFGThUpKB
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)

iD8DBQBHfd6p+jm90f8eFWYRArXmAJoCnFUkzbpkH1ndCjpJX9YUiMGiNwCfRmRx
LD+9ozn9aM6XQQzQZY06PBs=
=pqV0
-----END PGP SIGNATURE-----

--nextPart3738705.siFGThUpKB--

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 04 Jan 2008 07:17:24 +0000
From: Stefan Winter <[e-mail]>
Organization: Fondation RESTENA
To: [e-mail], "Alan DeKok" <[e-mail]>, [e-mail]
Subject: Re: Comments on "practical deployments"
Date: Fri, 4 Jan 2008 08:15:53 +0100
User-Agent: KMail/1.9.6 (enterprise 20070904.708012)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart4456099.OuFvFAhaBB"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>

--nextPart4456099.OuFvFAhaBB
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,

> In terms of major EAP deployments that support inter-domain roaming
> with substantial usage, one deployment (EDUROAM) is several orders of
> magnitude larger than any other that I am aware of.

I can confirm taht eduroam is EAP with mutual authentication only, and span=
s=20
some 35 countries right now; approx. 500 universities and other scientific=
=20
institutions. I'm not aware of any larger deployment in the world.

BTW, we do see some shortcomings of EAPoL and 802.1X, most notably the lack=
 of=20
properly informing the user what went wrong if something went wrong. But=20
that's another story and OT here I guess.

> As far as I know, EDUROAM does not use Diameter nor are there any
> major deployments of Diameter EAP.

We seriously considered it, but since Diameter+NASREQ+EAP + decent backend=
=20
connections didn't manifest implementation-wise, it was never taken further=
=2E=20
RadSec solved most of the problems we had.

Greetings,

Stefan Winter

=2D-=20
Stefan WINTER

Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale e=
t de=20
la Recherche
Ingenieur Forschung & Entwicklung

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
E-Mail: [e-mail] =A0 =A0 Tel.:  =A0 =A0+352 424409-1
http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0  =A0 Fax: =A0 =A0 =A0+352 422=
473

--nextPart4456099.OuFvFAhaBB
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)

iD8DBQBHfd0t+jm90f8eFWYRAopPAKCDPdCZRypXb409k8jRktJEVfyYLQCeL9pn
6VcvssXhSHnPqRsF+J3EMGw=
=Y+ec
-----END PGP SIGNATURE-----

--nextPart4456099.OuFvFAhaBB--

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 04 Jan 2008 06:22:07 +0000
DomainKey-Signature: s=qcdkim; d=qualcomm.com; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:Received:Received: X-MimeOLE:Content-class:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:Date:Message-ID: In-Reply-To:X-MS-Has-Attach:X-MS-TNEF-Correlator: Thread-Topic:Thread-Index:References:From:To:Cc: X-OriginalArrivalTime; b=K9qHA4OMKNawrIxYB8IroPk/T6r5Ohwqrz6Zn7HwXcSnul3MAtcaNJFt NedfY3UHJ4urizcIKVU+Q1zDamDbvL1u9hfk08mMcuJsvN9j5Aqb7GLzr HmmNvAV4aJfuDGHc3PI1WDWcXrMN6yJ0+g+3oyypyT2s0OXBFf0NcBWo2 w=;
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
Date: Thu, 3 Jan 2008 22:20:38 -0800
Message-ID: <[e-mail]>
Thread-Topic: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
Thread-Index: AchOaWvHQNI4Dr+2QNChxEkZFeCpzAAJg4FA
From: "Narayanan, Vidya" <[e-mail]>
To: "Dan Harkins" <[e-mail]>
Cc: "Alan DeKok" <[e-mail]>, "radext mailing list" <[e-mail]>, <[e-mail]>

Hi Dan,
There are two points here.  End-to-end protection of key material is
certainly feasible and is not prohibited by the model - it is quite
feasible in the enterprise space, for instance.  Even when hop-by-hop
protected, the proxies don't have authorization to use the DSRK.  It is
only meant for use by the local ER server. =20

For key separation, it is important to have different DSRKs per domain.
For instance, there must be separation between the rMSKs given to the
different NASs - if the same DSRK was given to multiple local ER
servers, you would end up with the same rMSK for multiple NASs.  We
could come up with other key separation techniques that keep the rMSK
unique, but that would mean introducing the domain or an equivalent
differentiation at that level instead of at the DSRK. =20

Also, another point is that Domain A and Domain B may actually be
different administrative domains, in which case, it is not necessarily
true that they have a business relationship with each other or that they
have the same level of relationship with the home domain.  So, there is
no assumption that any one visited domain is a proxy in the path between
another visited domain and the home domain.  Hence, ensuring proper key
separation at the DSRK level is important.=20

Regards,
Vidya

> -----Original Message-----
> From: Dan Harkins [mailto:[e-mail]]=20
> Sent: Thursday, January 03, 2008 4:33 PM
> To: Narayanan, Vidya
> Cc: Alan DeKok; radext mailing list; [e-mail]
> Subject: RE: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
>=20
>=20
>   Hi Vidya,
>=20
>   There may be proxies in between AAA-Home and Local ER=20
> server A and between AAA-Home and Local ER Server B. There is=20
> strong consensus in the group that there is no problem with=20
> this that all the proxies will behave themselves and not=20
> abuse the fact that they know DRSK1 and/or DRSK2. That being=20
> the case why cannot the same logic that justifies these=20
> proxies having such keying material be used to just give the=20
> same key to Local ER Server A and Local ER Server B? Why do=20
> we need to have different DRSKs? What problem are you trying=20
> to solve and isn't that problem still going to be there since=20
> proxies are now involved?
>=20
>   Dan.
>=20
> On Thu, January 3, 2008 3:02 pm, Narayanan, Vidya wrote:
> > Hi Alan,
> > Some of this is revisiting the HOKEY charter discussions and can be=20
> > found in the archives, but let me try a bit further to clarify here.
> >
> > Consider the following figure:
> >
> >                                    -----------
> >                                   | AAA-Home  |
> >                                    -----------
> >                                         |
> >                =20
> ------------------------------------------------------
> >                |                                           =20
>           |
> >        -------------------
> > -------------------
> >       | Local ER server A |                                =20
> | Local ER
> > server B |
> >       |    (Domain A)     |                                =20
> |    (Domain
> > B)     |
> >        -------------------
> > -------------------
> >                |                                           =20
>           |
> >           --------------
> > --------------
> >          |              |                                       |
> > |
> >      --------        --------                              =20
>  --------
> > --------
> >     | NAS A1 |      | NAS A2 |                             =20
> | NAS B1 |
> > | NAS B2 |
> >      --------        --------                              =20
>  --------
> > --------
> >
> >     ------
> >    | Peer |  ---------->
> >     ------
> >
> >
> > In the figure above, the peer is attached to a NAS (say,=20
> A1) in Domain=20
> > A, while its home domain corresponds to AAA-Home" which is=20
> potentially=20
> > much further away than Domain A is.  The first time around,=20
> the peer=20
> > authenticates with its home AAA server, which results in an=20
> MSK at NAS
> > A1 and an EMSK at AAA-Home.  This is in accordance with regular EAP=20
> > operation.  When the peer, the local domain and the AAA-Home also=20
> > support ERP, a DSRK (DSRK1) may be requested by the local=20
> ER server A=20
> > at the time of the EAP exchange.  DSRK1 is derived from the=20
> EMSK and=20
> > given to the Local ER Server A.  Now, when the peer moves=20
> from NAS A1=20
> > to NAS A2, it only needs to perform an ERP exchange with=20
> the Local ER Server A.
> > No exchange is required with AAA-Home.  This finishes much quicker=20
> > than an exchange that would have to go all the way to AAA-Home.
> >
> > It is when the peer moves from Domain A to Domain B that=20
> the peer has=20
> > to talk to AAA-Home again.  At this point, a DSRK2 may be given to=20
> > Local ER Server B, which then gets used for=20
> re-authentication within=20
> > that domain (say, when the peer moves from NAS B1 to NAS B2).
> >
> > As shown, all re-authentications within a local domain are=20
> restricted=20
> > to that domain with no exchanges needed with the home=20
> domain (unless=20
> > the DSRK expired).  Exchanges involve the home domain when the peer=20
> > crosses domain boundaries.
> >
> > Hope this helps.
> >
> > Thanks,
> > Vidya
> >
> >> -----Original Message-----
> >> From: Alan DeKok [mailto:[e-mail]]
> >> Sent: Thursday, January 03, 2008 2:01 PM
> >> To: Narayanan, Vidya
> >> Cc: [e-mail]; 'radext mailing list'
> >> Subject: Re: [HOKEY] Review of=20
> draft-gaonkar-radext-erp-attrs-02.txt
> >>
> >> Narayanan, Vidya wrote:
> >> > Thanks for the review.  Let me attempt to clarify a few=20
> things that=20
> >> > may answer majority of your questions below.  The DSRK=20
> is a domain=20
> >> > specific root key that is derived from the EMSK for the=20
> purpose of=20
> >> > having a local EAP Re-authentication server (ER server) in
> >> the visited domain.
> >>
> >>   I'm not sure I understand why.  If there isn't an EAP=20
> >> re-authentication server, then the EAP authentications will go=20
> >> through the local AAA server.  So there is significant benefit in=20
> >> *always* going through the local AAA server.  i.e.
> >> having the AAA servers cache the keys required for=20
> re-authentication.
> >>
> >> > "Visited domain" doesn't necessarily imply administrative
> >> in this case
> >> > - a large domain can be broken up into multiple smaller=20
> domains for=20
> >> > sake of efficient re-authentication.
> >>
> >>   I'm not sure I understand how this helps efficiency.  If there's=20
> >> one large domain for the initial authentication, then only=20
> one domain=20
> >> is needed.  If the home server can handle the=20
> re-authentication, then=20
> >> there's doubly no need for multiple domains.
> >>
> >> > This is done so that the latency involved in
> >> reauthentication at the
> >> > time of a handoff for a peer is minimal (the peer doesn't
> >> have to go
> >> > back to the home AAA server to get reauthenticated). =20
> When the peer=20
> >> > hands off across domains (i.e., leaves the boundary of an
> >> ER server),
> >> > it needs to communicate with the home AAA server to obtain
> >> a new DSRK
> >> > for the new ER server.  This may be done using a full EAP
> >> exchange or
> >> > with an ER exchange with the home AAA server.
> >>
> >>   If the re-authentication has to go back to the home AAA=20
> server for=20
> >> a to obtain a new DSRK, why are there multiple domains?  The home=20
> >> server is manifestly capable of handling all re-authentication=20
> >> requests.
> >>
> >> > The problem statement and use cases are described further in
> >> >
> >>=20
> http://www.ietf.org/internet-drafts/draft-ietf-hokey-reauth-ps-07.txt.
> >> > The ERX protocol draft itself describes the protocol in detail -
> >> >
> >>=20
> http://www.ietf.org/internet-drafts/draft-ietf-hokey-reauth-ps-07.txt
> >> > - figure 2, for instance, shows the recipient of the DSRK
> >> and how it
> >> > is further used for reauthentication during=20
> authenticator changes=20
> >> > within that domain.
> >>
> >>   I think I need to address many of my comments to that draft.
> >>
> >> > Hope this clarifies many of the things you ask below.  A
> >> few further
> >> > comments inline on the other questions.
> >>
> >>   It clarifies it a little.  I've gone over the problem statement=20
> >> draft, and have some questions about it.
> >>
> >> > Actually, this document has gone through a couple of
> >> contortions due
> >> > to lack of clarity from the RADIUS side on how to proceed here.
> >>
> >>   The radext WG is always available to answer questions.
> >> I've been lurking on hokey for a while, but until recently=20
> have been=20
> >> too busy to pay much attention to the drafts.
> >>
> >> > There will only be one key response, but the key name is
> >> still needed
> >> > so that the peer, upon reauthentication later, can refer=20
> to the key.
> >>
> >>   Ok... I have questions, but I'll address them to another=20
> draft, I=20
> >> think.
> >>
> >> > As I mentioned before, there is no goal to change the
> >> RADIUS security
> >> > measures.  This draft will also be updated to work with=20
> keywrap and=20
> >> > DTLS
> >>
> >>   I don't believe either method is strictly necessary for=20
> >> transporting these keys.  There are alternatives that=20
> should be able=20
> >> to work.
> >>
> >>   Alan DeKok.
> >>
> >
> > _______________________________________________
> > HOKEY mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/hokey
> >
>=20
>=20
>=20

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 04 Jan 2008 01:15:20 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Alan DeKok'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: E2E and crypto-agility
Date: Thu, 3 Jan 2008 17:14:06 -0800
Message-ID: <00f001c84e6f$1b0e5680$512b0380$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AchOYDVpn+zTyAEmRC+GrLd+7Fhq+wADEU1w
Content-Language: en-us

Glen Zorn wrote:
> It's hard to see how this solves any known problem.  We already know how
te
> secure the key on the wire; the only problem is with evil proxies.

  Um... if you don't trust the proxies, why are you letting them control
access to your network?
[gwz] 
The only purpose of which I'm aware for e2e encryption in RADIUS is the
hiding of the encrypted things from proxies.
[/gwz]

...


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Fri, 04 Jan 2008 00:34:22 +0000
Message-ID: <[e-mail]>
Date: Thu, 3 Jan 2008 16:33:05 -0800 (PST)
Subject: RE: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
From: "Dan Harkins" <[e-mail]>
To: "Narayanan, Vidya" <[e-mail]>
Cc: "Alan DeKok" <[e-mail]>, "radext mailing list" <[e-mail]>, [e-mail]
User-Agent: SquirrelMail/1.4.8
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit

  Hi Vidya,

  There may be proxies in between AAA-Home and Local ER server A
and between AAA-Home and Local ER Server B. There is strong consensus
in the group that there is no problem with this that all the proxies
will behave themselves and not abuse the fact that they know DRSK1
and/or DRSK2. That being the case why cannot the same logic that justifies
these proxies having such keying material be used to just give the
same key to Local ER Server A and Local ER Server B? Why do we need
to have different DRSKs? What problem are you trying to solve and isn't
that problem still going to be there since proxies are now involved?

  Dan.

On Thu, January 3, 2008 3:02 pm, Narayanan, Vidya wrote:
> Hi Alan,
> Some of this is revisiting the HOKEY charter discussions and can be
> found in the archives, but let me try a bit further to clarify here.
>
> Consider the following figure:
>
>                                    -----------
>                                   | AAA-Home  |
>                                    -----------
>                                         |
>                 ------------------------------------------------------
>                |                                                      |
>        -------------------
> -------------------
>       | Local ER server A |                                 | Local ER
> server B |
>       |    (Domain A)     |                                 |    (Domain
> B)     |
>        -------------------
> -------------------
>                |                                                      |
>           --------------
> --------------
>          |              |                                       |
> |
>      --------        --------                                --------
> --------
>     | NAS A1 |      | NAS A2 |                              | NAS B1 |
> | NAS B2 |
>      --------        --------                                --------
> --------
>
>     ------
>    | Peer |  ---------->
>     ------
>
>
> In the figure above, the peer is attached to a NAS (say, A1) in Domain
> A, while its home domain corresponds to AAA-Home" which is potentially
> much further away than Domain A is.  The first time around, the peer
> authenticates with its home AAA server, which results in an MSK at NAS
> A1 and an EMSK at AAA-Home.  This is in accordance with regular EAP
> operation.  When the peer, the local domain and the AAA-Home also
> support ERP, a DSRK (DSRK1) may be requested by the local ER server A at
> the time of the EAP exchange.  DSRK1 is derived from the EMSK and given
> to the Local ER Server A.  Now, when the peer moves from NAS A1 to NAS
> A2, it only needs to perform an ERP exchange with the Local ER Server A.
> No exchange is required with AAA-Home.  This finishes much quicker than
> an exchange that would have to go all the way to AAA-Home.
>
> It is when the peer moves from Domain A to Domain B that the peer has to
> talk to AAA-Home again.  At this point, a DSRK2 may be given to Local ER
> Server B, which then gets used for re-authentication within that domain
> (say, when the peer moves from NAS B1 to NAS B2).
>
> As shown, all re-authentications within a local domain are restricted to
> that domain with no exchanges needed with the home domain (unless the
> DSRK expired).  Exchanges involve the home domain when the peer crosses
> domain boundaries.
>
> Hope this helps.
>
> Thanks,
> Vidya
>
>> -----Original Message-----
>> From: Alan DeKok [mailto:[e-mail]]
>> Sent: Thursday, January 03, 2008 2:01 PM
>> To: Narayanan, Vidya
>> Cc: [e-mail]; 'radext mailing list'
>> Subject: Re: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
>>
>> Narayanan, Vidya wrote:
>> > Thanks for the review.  Let me attempt to clarify a few things that
>> > may answer majority of your questions below.  The DSRK is a domain
>> > specific root key that is derived from the EMSK for the purpose of
>> > having a local EAP Re-authentication server (ER server) in
>> the visited domain.
>>
>>   I'm not sure I understand why.  If there isn't an EAP
>> re-authentication server, then the EAP authentications will
>> go through the local AAA server.  So there is significant
>> benefit in *always* going through the local AAA server.  i.e.
>> having the AAA servers cache the keys required for re-authentication.
>>
>> > "Visited domain" doesn't necessarily imply administrative
>> in this case
>> > - a large domain can be broken up into multiple smaller domains for
>> > sake of efficient re-authentication.
>>
>>   I'm not sure I understand how this helps efficiency.  If
>> there's one large domain for the initial authentication, then
>> only one domain is needed.  If the home server can handle the
>> re-authentication, then there's doubly no need for multiple domains.
>>
>> > This is done so that the latency involved in
>> reauthentication at the
>> > time of a handoff for a peer is minimal (the peer doesn't
>> have to go
>> > back to the home AAA server to get reauthenticated).  When the peer
>> > hands off across domains (i.e., leaves the boundary of an
>> ER server),
>> > it needs to communicate with the home AAA server to obtain
>> a new DSRK
>> > for the new ER server.  This may be done using a full EAP
>> exchange or
>> > with an ER exchange with the home AAA server.
>>
>>   If the re-authentication has to go back to the home AAA
>> server for a to obtain a new DSRK, why are there multiple
>> domains?  The home server is manifestly capable of handling
>> all re-authentication requests.
>>
>> > The problem statement and use cases are described further in
>> >
>> http://www.ietf.org/internet-drafts/draft-ietf-hokey-reauth-ps-07.txt.
>> > The ERX protocol draft itself describes the protocol in detail -
>> >
>> http://www.ietf.org/internet-drafts/draft-ietf-hokey-reauth-ps-07.txt
>> > - figure 2, for instance, shows the recipient of the DSRK
>> and how it
>> > is further used for reauthentication during authenticator changes
>> > within that domain.
>>
>>   I think I need to address many of my comments to that draft.
>>
>> > Hope this clarifies many of the things you ask below.  A
>> few further
>> > comments inline on the other questions.
>>
>>   It clarifies it a little.  I've gone over the problem
>> statement draft, and have some questions about it.
>>
>> > Actually, this document has gone through a couple of
>> contortions due
>> > to lack of clarity from the RADIUS side on how to proceed here.
>>
>>   The radext WG is always available to answer questions.
>> I've been lurking on hokey for a while, but until recently
>> have been too busy to pay much attention to the drafts.
>>
>> > There will only be one key response, but the key name is
>> still needed
>> > so that the peer, upon reauthentication later, can refer to the key.
>>
>>   Ok... I have questions, but I'll address them to another
>> draft, I think.
>>
>> > As I mentioned before, there is no goal to change the
>> RADIUS security
>> > measures.  This draft will also be updated to work with keywrap and
>> > DTLS
>>
>>   I don't believe either method is strictly necessary for
>> transporting these keys.  There are alternatives that should
>> be able to work.
>>
>>   Alan DeKok.
>>
>
> _______________________________________________
> HOKEY mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/hokey
>



--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Thu, 03 Jan 2008 23:25:16 +0000
Message-ID: <[e-mail]>
Date: Fri, 04 Jan 2008 00:22:58 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Glen Zorn <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: E2E and crypto-agility
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:
> It's hard to see how this solves any known problem.  We already know how te
> secure the key on the wire; the only problem is with evil proxies.

  Um... if you don't trust the proxies, why are you letting them control
access to your network?

  RADIUS authentication routing is *not* IPv4 packet routing.  There are
commercial agreements in place for RADIUS traffic between any two
networks.  This isn't true for IPv4.

>  Since in
> the last step the end-user transmits K'' to the NAS (necessarily unencrypted
> since the peer & NAS do not yet share any keying material)

  The NAS can prove to the peer that it knows the encrypted key.  The
peer can then send the NAS the decryption key, or any other key
derivation function.

> you have
> basically divulged your key-encrypting key to the world, which of course
> includes any RADIUS proxies that were in the forwarding path.  So what does
> this help?

  Giving a key to the NAS is equivalent to giving it to the local AAA
server, because they are run by the same administrative entity.  So
*any* proposal that gives keying material to the NAS is vulnerable to
this attack.

  If the desire is to protect against third-party proxies, such as
roaming or interconnect providers, see my first set of comments.  In
addition, the local NAS (and AAA server) can choose to share that keying
material with anyone else in the world, including RADIUS proxies.  This
is true today.

  The MPPE keys used for 802.1x keying today are shared in the clear
with all RADIUS proxies.  Is there a *real-world* problem we're trying
to solve here, or a theoretical exercise that is made moot by real-world
business realities?

  Alan DeKok.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Thu, 03 Jan 2008 23:07:24 +0000
Message-ID: <[e-mail]>
Date: Fri, 04 Jan 2008 00:05:18 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: "Narayanan, Vidya" <[e-mail]>
CC: [e-mail], radext mailing list <[e-mail]>
Subject: Re: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Narayanan, Vidya wrote:
> Some of this is revisiting the HOKEY charter discussions and can be
> found in the archives, but let me try a bit further to clarify here. 

  I don't want to re-visit the charter.  I think there may be more than
one way to achieve the goals.

  Alan DeKok.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Thu, 03 Jan 2008 23:05:15 +0000
From: "Glen Zorn" <[e-mail]>
To: "'Alan DeKok'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: E2E and crypto-agility
Date: Thu, 3 Jan 2008 15:04:17 -0800
Message-ID: <00b101c84e5c$f7e0c600$e7a25200$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AchIc3mu07zKmtxlSbS8ljbDlVVydAF55IWw
Content-Language: en-us

...

  Back to my earlier question about "end to end", I think the only ends
that matter are the end user and home server.  The NAS is in contact
with both, and can leverage it's relationship with the end user to do
things that are normally impossible in RADIUS.   If we assume that the
end user and home RADIUS server can independently derive keying
material, then the server can supply keying material to the NAS, and the
end user can do the same.  The NAS can then derive keying material,
without it being exposed to anyone else.

  e.g. RADIUS, end-user: derive K', K''
       RADIUS -> NAS: E = ENC(K')         (using key K'')
       end-user -> NAS: K''

  If we assume that each RADIUS hop also encrypts E using the
Tunnel-Password method:

       T = tunnel_encrypt(per-hop-secret, E)

  Then we have the following properties:

  - no RADIUS proxy knows K' (they only know E)
  - The NAS can derive K' from E and K''
  - an attacker watching RADIUS only knows T
  - an attacker watching the end-user traffic only knows K''
  - an attacker watching *both* RADIUS and supplicant traffic knows
    T and K'', which is insufficient to derive K'
  - any intermediary RADIUS proxy that handles tunnel-password
    encryption can transport E.
[gwz] 
It's hard to see how this solves any known problem.  We already know how te
secure the key on the wire; the only problem is with evil proxies.  Since in
the last step the end-user transmits K'' to the NAS (necessarily unencrypted
since the peer & NAS do not yet share any keying material) you have
basically divulged your key-encrypting key to the world, which of course
includes any RADIUS proxies that were in the forwarding path.  So what does
this help?
[/gwz] 



--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Thu, 03 Jan 2008 23:03:57 +0000
DomainKey-Signature: s=qcdkim; d=qualcomm.com; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:Received:Received: X-MimeOLE:Content-class:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:Date:Message-ID: In-Reply-To:X-MS-Has-Attach:X-MS-TNEF-Correlator: Thread-Topic:Thread-Index:References:From:To:Cc: X-OriginalArrivalTime; b=A4JTYlWVlb8B/I/65LzWgfscBAktHRAVDyv76ywu98ir/j3bjv+myAfI NFTCjdhy47K3YACcn9uIPdmmq8M8qFdSA1oevS7qqF7mNLryLb6fjCnx8 uSMC+C+fR4yrVeTOEMfyTFx58ltVjh8aw+oWvFt5cdUqmqtb3+pnMKIQN 8=;
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
Date: Thu, 3 Jan 2008 15:02:22 -0800
Message-ID: <[e-mail]>
Thread-Topic: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
Thread-Index: AchOVGV0Go306gAkSfC9FgbF/UaBPwAA8p4A
From: "Narayanan, Vidya" <[e-mail]>
To: "Alan DeKok" <[e-mail]>
Cc: <[e-mail]>, "radext mailing list" <[e-mail]>

Hi Alan,
Some of this is revisiting the HOKEY charter discussions and can be
found in the archives, but let me try a bit further to clarify here.=20

Consider the following figure:=20

                                   -----------
                                  | AAA-Home  |
                                   -----------
                                        |
                ------------------------------------------------------
               |                                                      |
       -------------------
-------------------
      | Local ER server A |                                 | Local ER
server B |
      |    (Domain A)     |                                 |    (Domain
B)     |
       -------------------
-------------------
               |                                                      |
          --------------
--------------
         |              |                                       |
|
     --------        --------                                --------
--------
    | NAS A1 |      | NAS A2 |                              | NAS B1 |
| NAS B2 |
     --------        --------                                --------
--------

    ------
   | Peer |  ---------->
    ------


In the figure above, the peer is attached to a NAS (say, A1) in Domain
A, while its home domain corresponds to AAA-Home" which is potentially
much further away than Domain A is.  The first time around, the peer
authenticates with its home AAA server, which results in an MSK at NAS
A1 and an EMSK at AAA-Home.  This is in accordance with regular EAP
operation.  When the peer, the local domain and the AAA-Home also
support ERP, a DSRK (DSRK1) may be requested by the local ER server A at
the time of the EAP exchange.  DSRK1 is derived from the EMSK and given
to the Local ER Server A.  Now, when the peer moves from NAS A1 to NAS
A2, it only needs to perform an ERP exchange with the Local ER Server A.
No exchange is required with AAA-Home.  This finishes much quicker than
an exchange that would have to go all the way to AAA-Home. =20

It is when the peer moves from Domain A to Domain B that the peer has to
talk to AAA-Home again.  At this point, a DSRK2 may be given to Local ER
Server B, which then gets used for re-authentication within that domain
(say, when the peer moves from NAS B1 to NAS B2). =20

As shown, all re-authentications within a local domain are restricted to
that domain with no exchanges needed with the home domain (unless the
DSRK expired).  Exchanges involve the home domain when the peer crosses
domain boundaries. =20

Hope this helps. =20

Thanks,
Vidya

> -----Original Message-----
> From: Alan DeKok [mailto:[e-mail]]=20
> Sent: Thursday, January 03, 2008 2:01 PM
> To: Narayanan, Vidya
> Cc: [e-mail]; 'radext mailing list'
> Subject: Re: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
>=20
> Narayanan, Vidya wrote:
> > Thanks for the review.  Let me attempt to clarify a few things that=20
> > may answer majority of your questions below.  The DSRK is a domain=20
> > specific root key that is derived from the EMSK for the purpose of=20
> > having a local EAP Re-authentication server (ER server) in=20
> the visited domain.
>=20
>   I'm not sure I understand why.  If there isn't an EAP=20
> re-authentication server, then the EAP authentications will=20
> go through the local AAA server.  So there is significant=20
> benefit in *always* going through the local AAA server.  i.e.=20
> having the AAA servers cache the keys required for re-authentication.
>=20
> > "Visited domain" doesn't necessarily imply administrative=20
> in this case=20
> > - a large domain can be broken up into multiple smaller domains for=20
> > sake of efficient re-authentication.
>=20
>   I'm not sure I understand how this helps efficiency.  If=20
> there's one large domain for the initial authentication, then=20
> only one domain is needed.  If the home server can handle the=20
> re-authentication, then there's doubly no need for multiple domains.
>=20
> > This is done so that the latency involved in=20
> reauthentication at the=20
> > time of a handoff for a peer is minimal (the peer doesn't=20
> have to go=20
> > back to the home AAA server to get reauthenticated).  When the peer=20
> > hands off across domains (i.e., leaves the boundary of an=20
> ER server),=20
> > it needs to communicate with the home AAA server to obtain=20
> a new DSRK=20
> > for the new ER server.  This may be done using a full EAP=20
> exchange or=20
> > with an ER exchange with the home AAA server.
>=20
>   If the re-authentication has to go back to the home AAA=20
> server for a to obtain a new DSRK, why are there multiple=20
> domains?  The home server is manifestly capable of handling=20
> all re-authentication requests.
>=20
> > The problem statement and use cases are described further in=20
> >=20
> http://www.ietf.org/internet-drafts/draft-ietf-hokey-reauth-ps-07.txt.
> > The ERX protocol draft itself describes the protocol in detail -=20
> >=20
> http://www.ietf.org/internet-drafts/draft-ietf-hokey-reauth-ps-07.txt=20
> > - figure 2, for instance, shows the recipient of the DSRK=20
> and how it=20
> > is further used for reauthentication during authenticator changes=20
> > within that domain.
>=20
>   I think I need to address many of my comments to that draft.
>=20
> > Hope this clarifies many of the things you ask below.  A=20
> few further=20
> > comments inline on the other questions.
>=20
>   It clarifies it a little.  I've gone over the problem=20
> statement draft, and have some questions about it.
>=20
> > Actually, this document has gone through a couple of=20
> contortions due=20
> > to lack of clarity from the RADIUS side on how to proceed here.
>=20
>   The radext WG is always available to answer questions. =20
> I've been lurking on hokey for a while, but until recently=20
> have been too busy to pay much attention to the drafts.
>=20
> > There will only be one key response, but the key name is=20
> still needed=20
> > so that the peer, upon reauthentication later, can refer to the key.
>=20
>   Ok... I have questions, but I'll address them to another=20
> draft, I think.
>=20
> > As I mentioned before, there is no goal to change the=20
> RADIUS security=20
> > measures.  This draft will also be updated to work with keywrap and=20
> > DTLS
>=20
>   I don't believe either method is strictly necessary for=20
> transporting these keys.  There are alternatives that should=20
> be able to work.
>=20
>   Alan DeKok.
>=20

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Thu, 03 Jan 2008 22:04:03 +0000
Message-ID: <[e-mail]>
Date: Thu, 03 Jan 2008 23:00:51 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: "Narayanan, Vidya" <[e-mail]>
CC: [e-mail], 'radext mailing list' <[e-mail]>
Subject: Re: [HOKEY] Review of draft-gaonkar-radext-erp-attrs-02.txt
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Narayanan, Vidya wrote:
> Thanks for the review.  Let me attempt to clarify a few things that may
> answer majority of your questions below.  The DSRK is a domain specific
> root key that is derived from the EMSK for the purpose of having a local
> EAP Re-authentication server (ER server) in the visited domain.

  I'm not sure I understand why.  If there isn't an EAP
re-authentication server, then the EAP authentications will go through
the local AAA server.  So there is significant benefit in *always* going
through the local AAA server.  i.e. having the AAA servers cache the
keys required for re-authentication.

> "Visited domain" doesn't necessarily imply administrative in this case -
> a large domain can be broken up into multiple smaller domains for sake
> of efficient re-authentication.  

  I'm not sure I understand how this helps efficiency.  If there's one
large domain for the initial authentication, then only one domain is
needed.  If the home server can handle the re-authentication, then
there's doubly no need for multiple domains.

> This is done so that the latency involved in reauthentication at the
> time of a handoff for a peer is minimal (the peer doesn't have to go
> back to the home AAA server to get reauthenticated).  When the peer
> hands off across domains (i.e., leaves the boundary of an ER server), it
> needs to communicate with the home AAA server to obtain a new DSRK for
> the new ER server.  This may be done using a full EAP exchange or with
> an ER exchange with the home AAA server.  

  If the re-authentication has to go back to the home AAA server for a
to obtain a new DSRK, why are there multiple domains?  The home server
is manifestly capable of handling all re-authentication requests.

> The problem statement and use cases are described further in
> http://www.ietf.org/internet-drafts/draft-ietf-hokey-reauth-ps-07.txt.
> The ERX protocol draft itself describes the protocol in detail -
> http://www.ietf.org/internet-drafts/draft-ietf-hokey-reauth-ps-07.txt -
> figure 2, for instance, shows the recipient of the DSRK and how it is
> further used for reauthentication during authenticator changes within
> that domain.  

  I think I need to address many of my comments to that draft.

> Hope this clarifies many of the things you ask below.  A few further
> comments inline on the other questions. 

  It clarifies it a little.  I've gone over the problem statement draft,
and have some questions about it.

> Actually, this document has gone through a couple of contortions due to
> lack of clarity from the RADIUS side on how to proceed here.

  The radext WG is always available to answer questions.  I've been
lurking on hokey for a while, but until recently have been too busy to
pay much attention to the drafts.

> There will only be one key response, but the key name is still needed so
> that the peer, upon reauthentication later, can refer to the key.

  Ok... I have questions, but I'll address them to another draft, I think.

> As I mentioned before, there is no goal to change the RADIUS security
> measures.  This draft will also be updated to work with keywrap and DTLS

  I don't believe either method is strictly necessary for transporting
these keys.  There are alternatives that should be able to work.

  Alan DeKok.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Thu, 03 Jan 2008 17:08:46 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_72921a68-2af9-4fd8-beb7-b0b686974df4_"
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Proposed Resolution to Issue
Date: Thu, 3 Jan 2008 09:07:16 -0800
MIME-Version: 1.0

--_72921a68-2af9-4fd8-beb7-b0b686974df4_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


FYI.  Here are the proposed changes to RFC 5090 to address the problems tha=
t Mike found in Appendix A.=20
> Subject: RE: AUTH48 [SG]: RFC 5090 <draft-ietf-radext-rfc4590bis-02.txt> =
NOW AVAILABLE> Date: Thu, 3 Jan 2008 17:07:13 +0200> From: Baruch.Sterman@K=
ayote.com> To: [e-mail]; [e-mail]> CC: david.sc=
[e-mail]; [e-mail]; [e-mail]; dromasca@avaya.=
com; [e-mail]; [e-mail]; [e-mail]=
> > Here are corrections to the examples as per David's input. I hope this>=
 will put all of the outstanding issues to rest so that we can all sign> of=
f on the document. > > There are essentially 2 corrections. In each example=
, the response> should be changed in two places.> > On page 24, change:> > =
> A->B> > INVITE sip:[e-mail] SIP/2.0> Proxy-Authorization: =
Digest algorithm=3D"md5",nonce=3D"3bada1a0"> ,realm=3D"example.com"> ,respo=
nse=3D"7679b84a560835846ec553174dbabb69"> ,uri=3D"sip:97226491335@example.c=
om",username=3D"12345678"> ,qop=3Dauth,algorithm=3DMD5> ,cnonce=3D"56593a80=
,nc=3D"00000001"> > From: <sip:[e-mail]>> To: <sip:97226491335@=
example.com>> > > B->C> > Code =3D Access-Request (1)> Packet identifier =
=3D 0x7d (125)> Length =3D 221> Authenticator =3D F5E55840E324AA49D216D9DBD=
069807D> NAS-IP-Address =3D 192.0.2.38> NAS-Port =3D 5> User-Name =3D 12345=
678> Digest-Method =3D INVITE> Digest-URI =3D sip:[e-mail]> =
Digest-Realm =3D example.com> Digest-Qop =3D auth> Digest-Algorithm =3D MD5=
> Digest-CNonce =3D 56593a80> Digest-Nonce =3D 3bada1a0> Digest-Nonce-Count=
 =3D 00000001> Digest-Response =3D 7679b84a560835846ec553174dbabb69> Digest=
-Username =3D 12345678> SIP-AOR =3D sip:[e-mail]> Message-Authe=
nticator =3D BD037498E8385878A46ECF4D5F8D2B48> > > To> > A->B> > INVITE sip=
:[e-mail] SIP/2.0> Proxy-Authorization: Digest algorithm=3D"=
md5",nonce=3D"3bada1a0"> ,realm=3D"example.com"> ,response=3D"756933f735fcd=
93f90a4bbdd5467f263"> ,uri=3D"sip:[e-mail]",username=3D"1234=
5678"> ,qop=3Dauth,algorithm=3DMD5> ,cnonce=3D"56593a80,nc=3D"00000001"> > =
From: <sip:[e-mail]>> To: <sip:[e-mail]>> > > B-=
>C> > Code =3D Access-Request (1)> Packet identifier =3D 0x7d (125)> Length=
 =3D 221> Authenticator =3D F5E55840E324AA49D216D9DBD069807D> NAS-IP-Addres=
s =3D 192.0.2.38> NAS-Port =3D 5> User-Name =3D 12345678> Digest-Method =3D=
 INVITE> Digest-URI =3D sip:[e-mail]> Digest-Realm =3D examp=
le.com> Digest-Qop =3D auth> Digest-Algorithm =3D MD5> Digest-CNonce =3D 56=
593a80> Digest-Nonce =3D 3bada1a0> Digest-Nonce-Count =3D 00000001> Digest-=
Response =3D 756933f735fcd93f90a4bbdd5467f263> Digest-Username =3D 12345678=
> SIP-AOR =3D sip:[e-mail]> Message-Authenticator =3D BD037498E=
8385878A46ECF4D5F8D2B48> > > And on page 26, change> > > > A->B> > GET /ind=
ex.html HTTP/1.1> Authorization: Digest algorithm=3DMD5,qop=3Dauth,nonce=3D=
"a3086ac8"> ,nc=3D"00000001",cnonce=3D"56593a78"> ,realm=3D"example.com"> ,=
response=3D"ba623217b5ec024d30c4aaef9d8494de"> ,uri=3D"/index.html",usernam=
e=3D"12345678"> > B->C> > Code =3D Access-Request (1)> Packet identifier =
=3D 0x7f (127)> Length =3D 176> Authenticator =3D F5E55840E324AA49D216D9DBD=
069807F> NAS-IP-Address =3D 192.0.2.38> NAS-Port =3D 5> User-Name =3D 12345=
678> Digest-Method =3D GET> Digest-URI =3D /index.html> Digest-Realm =3D ex=
ample.com> Digest-Qop =3D auth> Digest-Algorithm =3D MD5> Digest-CNonce =3D=
 56593a80> Digest-Nonce =3D a3086ac8> Digest-Nonce-Count =3D 00000001> Dige=
st-Response =3D ba623217b5ec024d30c4aaef9d8494de> Digest-Username =3D 12345=
678> Message-Authenticator =3D C360BFCEDFFBCE893469E802013DA5AA> > > To> > =
> > A->B> > GET /index.html HTTP/1.1> Authorization: Digest algorithm=3DMD5=
,qop=3Dauth,nonce=3D"a3086ac8"> ,nc=3D"00000001",cnonce=3D"56593a78"> ,real=
m=3D"example.com"> ,response=3D" a4fac45c27a30f4f244c54a2e99fa117"> ,uri=3D=
"/index.html",username=3D"12345678"> > B->C> > Code =3D Access-Request (1)>=
 Packet identifier =3D 0x7f (127)> Length =3D 176> Authenticator =3D F5E558=
40E324AA49D216D9DBD069807F> NAS-IP-Address =3D 192.0.2.38> NAS-Port =3D 5> =
User-Name =3D 12345678> Digest-Method =3D GET> Digest-URI =3D /index.html> =
Digest-Realm =3D example.com> Digest-Qop =3D auth> Digest-Algorithm =3D MD5=
> Digest-CNonce =3D 56593a80> Digest-Nonce =3D a3086ac8> Digest-Nonce-Count=
 =3D 00000001> Digest-Response =3D a4fac45c27a30f4f244c54a2e99fa117> Digest=
-Username =3D 12345678> Message-Authenticator =3D C360BFCEDFFBCE893469E8020=
13DA5AA> > > > > Thanks to David and group.> > Baruch> > =

--_72921a68-2af9-4fd8-beb7-b0b686974df4_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
FYI.&nbsp; Here are the proposed changes to RFC 5090 to address the problem=
s that Mike found in Appendix A. <BR>
<BR>&gt; Subject: RE: AUTH48 [SG]: RFC 5090 &lt;draft-ietf-radext-rfc4590bi=
s-02.txt&gt; NOW AVAILABLE<BR>&gt; Date: Thu, 3 Jan 2008 17:07:13 +0200<BR>=
&gt; From: [e-mail]<BR>&gt; To: [e-mail];=
 [e-mail]<BR>&gt; CC: [e-mail]; dscreat@dscre=
at.com; [e-mail]; [e-mail]; [e-mail]; d.b.nels=
[e-mail]; [e-mail]<BR>&gt; <BR>&gt; Here are correct=
ions to the examples as per David's input. I hope this<BR>&gt; will put all=
 of the outstanding issues to rest so that we can all sign<BR>&gt; off on t=
he document. <BR>&gt; <BR>&gt; There are essentially 2 corrections. In each=
 example, the response<BR>&gt; should be changed in two places.<BR>&gt; <BR=
>&gt; On page 24, change:<BR>&gt; <BR>&gt; <BR>&gt; A-&gt;B<BR>&gt; <BR>&gt=
; INVITE sip:[e-mail] SIP/2.0<BR>&gt; Proxy-Authorization: D=
igest algorithm=3D"md5",nonce=3D"3bada1a0"<BR>&gt; ,realm=3D"example.com"<B=
R>&gt; ,response=3D"7679b84a560835846ec553174dbabb69"<BR>&gt; ,uri=3D"sip:9=
[e-mail]",username=3D"12345678"<BR>&gt; ,qop=3Dauth,algorithm=
=3DMD5<BR>&gt; ,cnonce=3D"56593a80,nc=3D"00000001"<BR>&gt; <BR>&gt; From: &=
lt;sip:[e-mail]&gt;<BR>&gt; To: &lt;sip:[e-mail]=
&gt;<BR>&gt; <BR>&gt; <BR>&gt; B-&gt;C<BR>&gt; <BR>&gt; Code =3D Access-Req=
uest (1)<BR>&gt; Packet identifier =3D 0x7d (125)<BR>&gt; Length =3D 221<BR=
>&gt; Authenticator =3D F5E55840E324AA49D216D9DBD069807D<BR>&gt; NAS-IP-Add=
ress =3D 192.0.2.38<BR>&gt; NAS-Port =3D 5<BR>&gt; User-Name =3D 12345678<B=
R>&gt; Digest-Method =3D INVITE<BR>&gt; Digest-URI =3D sip:97226491335@exam=
ple.com<BR>&gt; Digest-Realm =3D example.com<BR>&gt; Digest-Qop =3D auth<BR=
>&gt; Digest-Algorithm =3D MD5<BR>&gt; Digest-CNonce =3D 56593a80<BR>&gt; D=
igest-Nonce =3D 3bada1a0<BR>&gt; Digest-Nonce-Count =3D 00000001<BR>&gt; Di=
gest-Response =3D 7679b84a560835846ec553174dbabb69<BR>&gt; Digest-Username =
=3D 12345678<BR>&gt; SIP-AOR =3D sip:[e-mail]<BR>&gt; Message-A=
uthenticator =3D BD037498E8385878A46ECF4D5F8D2B48<BR>&gt; <BR>&gt; <BR>&gt;=
 To<BR>&gt; <BR>&gt; A-&gt;B<BR>&gt; <BR>&gt; INVITE sip:97226491335@exampl=
e.com SIP/2.0<BR>&gt; Proxy-Authorization: Digest algorithm=3D"md5",nonce=
=3D"3bada1a0"<BR>&gt; ,realm=3D"example.com"<BR>&gt; ,response=3D"756933f73=
5fcd93f90a4bbdd5467f263"<BR>&gt; ,uri=3D"sip:[e-mail]",usern=
ame=3D"12345678"<BR>&gt; ,qop=3Dauth,algorithm=3DMD5<BR>&gt; ,cnonce=3D"565=
93a80,nc=3D"00000001"<BR>&gt; <BR>&gt; From: &lt;sip:[e-mail]&g=
t;<BR>&gt; To: &lt;sip:[e-mail]&gt;<BR>&gt; <BR>&gt; <BR>&gt=
; B-&gt;C<BR>&gt; <BR>&gt; Code =3D Access-Request (1)<BR>&gt; Packet ident=
ifier =3D 0x7d (125)<BR>&gt; Length =3D 221<BR>&gt; Authenticator =3D F5E55=
840E324AA49D216D9DBD069807D<BR>&gt; NAS-IP-Address =3D 192.0.2.38<BR>&gt; N=
AS-Port =3D 5<BR>&gt; User-Name =3D 12345678<BR>&gt; Digest-Method =3D INVI=
TE<BR>&gt; Digest-URI =3D sip:[e-mail]<BR>&gt; Digest-Realm =
=3D example.com<BR>&gt; Digest-Qop =3D auth<BR>&gt; Digest-Algorithm =3D MD=
5<BR>&gt; Digest-CNonce =3D 56593a80<BR>&gt; Digest-Nonce =3D 3bada1a0<BR>&=
gt; Digest-Nonce-Count =3D 00000001<BR>&gt; Digest-Response =3D 756933f735f=
cd93f90a4bbdd5467f263<BR>&gt; Digest-Username =3D 12345678<BR>&gt; SIP-AOR =
=3D sip:[e-mail]<BR>&gt; Message-Authenticator =3D BD037498E838=
5878A46ECF4D5F8D2B48<BR>&gt; <BR>&gt; <BR>&gt; And on page 26, change<BR>&g=
t; <BR>&gt; <BR>&gt; <BR>&gt; A-&gt;B<BR>&gt; <BR>&gt; GET /index.html HTTP=
/1.1<BR>&gt; Authorization: Digest algorithm=3DMD5,qop=3Dauth,nonce=3D"a308=
6ac8"<BR>&gt; ,nc=3D"00000001",cnonce=3D"56593a78"<BR>&gt; ,realm=3D"exampl=
e.com"<BR>&gt; ,response=3D"ba623217b5ec024d30c4aaef9d8494de"<BR>&gt; ,uri=
=3D"/index.html",username=3D"12345678"<BR>&gt; <BR>&gt; B-&gt;C<BR>&gt; <BR=
>&gt; Code =3D Access-Request (1)<BR>&gt; Packet identifier =3D 0x7f (127)<=
BR>&gt; Length =3D 176<BR>&gt; Authenticator =3D F5E55840E324AA49D216D9DBD0=
69807F<BR>&gt; NAS-IP-Address =3D 192.0.2.38<BR>&gt; NAS-Port =3D 5<BR>&gt;=
 User-Name =3D 12345678<BR>&gt; Digest-Method =3D GET<BR>&gt; Digest-URI =
=3D /index.html<BR>&gt; Digest-Realm =3D example.com<BR>&gt; Digest-Qop =3D=
 auth<BR>&gt; Digest-Algorithm =3D MD5<BR>&gt; Digest-CNonce =3D 56593a80<B=
R>&gt; Digest-Nonce =3D a3086ac8<BR>&gt; Digest-Nonce-Count =3D 00000001<BR=
>&gt; Digest-Response =3D ba623217b5ec024d30c4aaef9d8494de<BR>&gt; Digest-U=
sername =3D 12345678<BR>&gt; Message-Authenticator =3D C360BFCEDFFBCE893469=
E802013DA5AA<BR>&gt; <BR>&gt; <BR>&gt; To<BR>&gt; <BR>&gt; <BR>&gt; <BR>&gt=
; A-&gt;B<BR>&gt; <BR>&gt; GET /index.html HTTP/1.1<BR>&gt; Authorization: =
Digest algorithm=3DMD5,qop=3Dauth,nonce=3D"a3086ac8"<BR>&gt; ,nc=3D"0000000=
1",cnonce=3D"56593a78"<BR>&gt; ,realm=3D"example.com"<BR>&gt; ,response=3D"=
 a4fac45c27a30f4f244c54a2e99fa117"<BR>&gt; ,uri=3D"/index.html",username=3D=
"12345678"<BR>&gt; <BR>&gt; B-&gt;C<BR>&gt; <BR>&gt; Code =3D Access-Reques=
t (1)<BR>&gt; Packet identifier =3D 0x7f (127)<BR>&gt; Length =3D 176<BR>&g=
t; Authenticator =3D F5E55840E324AA49D216D9DBD069807F<BR>&gt; NAS-IP-Addres=
s =3D 192.0.2.38<BR>&gt; NAS-Port =3D 5<BR>&gt; User-Name =3D 12345678<BR>&=
gt; Digest-Method =3D GET<BR>&gt; Digest-URI =3D /index.html<BR>&gt; Digest=
-Realm =3D example.com<BR>&gt; Digest-Qop =3D auth<BR>&gt; Digest-Algorithm=
 =3D MD5<BR>&gt; Digest-CNonce =3D 56593a80<BR>&gt; Digest-Nonce =3D a3086a=
c8<BR>&gt; Digest-Nonce-Count =3D 00000001<BR>&gt; Digest-Response =3D a4fa=
c45c27a30f4f244c54a2e99fa117<BR>&gt; Digest-Username =3D 12345678<BR>&gt; M=
essage-Authenticator =3D C360BFCEDFFBCE893469E802013DA5AA<BR>&gt; <BR>&gt; =
<BR>&gt; <BR>&gt; <BR>&gt; Thanks to David and group.<BR>&gt; <BR>&gt; Baru=
ch<BR>&gt; <BR>&gt; <BR><BR></body>
</html>=

--_72921a68-2af9-4fd8-beb7-b0b686974df4_--

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Thu, 03 Jan 2008 08:55:37 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_092f2560-0514-4f2e-a822-026db3f5c7a1_"
From: Bernard Aboba <[e-mail]>
To: Alan DeKok <[e-mail]>, Glen Zorn <[e-mail]>
CC: <[e-mail]>
Subject: RE: Questions on modified Extended Attribute format?
Date: Thu, 3 Jan 2008 00:54:25 -0800
MIME-Version: 1.0

--_092f2560-0514-4f2e-a822-026db3f5c7a1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


> This proposal breaks that completely. It will be perfectly legal for> imp=
lementations of your proposal to put ALL RADIUS attributes as> grouped, ins=
ide of an "extended attribute". Any NAS that receives such> a response will=
 get a packet containing *nothing* but VSA's. It will> then decide that the=
re is nothing in the packet that it recognizes, and> will fail.
>
> i.e. your proposal creates a new protocol that is incompatible with> lega=
cy RADIUS.
=20
Presumbably new attributes using the extended format will define=20
whether they can be grouped or not, and if so, what the grouping
means. =20
=20
But what about legacy attributes?  For example, what would it mean for a=20
NAS-Identifier attribute to be grouped with say, a Tunnel-Password
attribute?   Presumably, this document would not define the semantics
of grouping for legacy attributes, which begs the question of where,
if anywhere, that semantic would be specified. =20
=20
Unless that semantic is specified somewhere (and I doubt it would be
specified anywhere for a substantial period of time), then the semantics
of grouping of legacy attributes is likely to be "implementation specific".=
=20
=20
So not only would the "new" RADIUS not be backward compatible with
the old one -- it wouldn't even have a public specification. =

--_092f2560-0514-4f2e-a822-026db3f5c7a1_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class=3D'hmmessage'>
<BR>&gt; This proposal breaks that completely. It will be perfectly legal f=
or<BR>&gt; implementations of your proposal to put ALL RADIUS attributes as=
<BR>&gt; grouped, inside of an "extended attribute". Any NAS that receives =
such<BR>&gt; a response will get a packet containing *nothing* but VSA's. I=
t will<BR>&gt; then decide that there is nothing in the packet that it reco=
gnizes, and<BR>&gt; will fail.<BR>
&gt;<BR>
&gt; i.e. your proposal creates a new protocol that is incompatible with<BR=
>&gt; legacy RADIUS.<BR>
&nbsp;<BR>
Presumbably new attributes using the extended format will define <BR>
whether they can be grouped or not, and if so, what the grouping<BR>
means.&nbsp; <BR>
&nbsp;<BR>
But what about legacy attributes?&nbsp; For example, what would it mean for=
 a <BR>
NAS-Identifier attribute to be grouped with say, a Tunnel-Password<BR>
attribute?&nbsp;&nbsp; Presumably, this document would not define the seman=
tics<BR>
of grouping for legacy attributes, which begs the question of where,<BR>
if anywhere, that semantic would be specified.&nbsp; <BR>
&nbsp;<BR>
Unless that semantic is specified somewhere (and I doubt it would be<BR>
specified anywhere for a substantial period of time), then the semantics<BR=
>
of grouping of legacy attributes is likely to be "implementation specific".=
 <BR>
&nbsp;<BR>
So not only would the "new" RADIUS not be backward compatible with<BR>
the old one -- it wouldn't even have a public specification. <BR></body>
</html>=

--_092f2560-0514-4f2e-a822-026db3f5c7a1_--

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Thu, 03 Jan 2008 05:03:01 +0000
Message-ID: <[e-mail]>
Date: Thu, 03 Jan 2008 06:00:44 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: 'radext mailing list' <[e-mail]>, [e-mail],  Lakshminath Dondeti <[e-mail]>, [e-mail]
Subject: Review of draft-gaonkar-radext-erp-attrs-02.txt
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

  I've read the draft, and have a few comments.

   These
   attributes can be used by a visited network entity to request a key
   from the home network and the home domain to deliver the key to the
   visited network entity

  Why is the visited network requesting keys?  Is the user involved in
this request?  Does the user know that the visited network is requesting
keys on his behalf?

  These issues are referenced in the security section.  However, that
section says that channel bindings *may* be necessary.  It looks to me
like they are required to avoid a large class of security / information
leakage.

   The key-request attribute contains the requesting entity's identity
   and the type of the key being requested.

  Why is it necessary to have the requesting entities identity?  Can
multiple servers in a proxy chain make requests at the same time?  If
so, why?  What benefit does this serve?

   The key-response attribute contains the requesting entity's identity,
   the type of the key, the key itself, its length, name and lifetime.

  Are key lifetimes different from user session lifetimes?  RADIUS
already has support for Session-Timeout, which would seem to put an
upper limit on key lifetimes, at least for one session.  Are these keys
to be cached across multiple user sessions?  If so, this document should
say.

[ key request attribute ]

      The Requesting Entity's Identity is to be copied in the
      corresponding Key-Response attribute.

  The following section says that the response MAY include the identity.
   That section then says the identity "is to be included".  The text
should agree with itself.

  The next section says that the identity can be only 192 octets in
length, but that limitation is not discussed here.  It should be.

  The guidelines document discusses packing multiple fields into one
attribute:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-02.txt

  The document doesn't say whether or not only one key-request attribute
is permitted in an Access-Request.  If only one is permitted, then all
of the packed fields in both attributes MUST be broken out into separate
attributes.  That will enable legacy implementations to deal with the
attributes.  i.e. not only support them, but enforce policies based on them.

  What is the purpose of the "key name" field?  This document doesn't
say, and it doesn't refer to other documents which could explain the
utility of that field.  Including a key name in a key response attribute
would seem to indicate that more than one key response is permitted in
an Access-Accept.  If so, this needs to be explained, including
use-cases.  If not, the key name is not needed.

      A stricter version of RFC 3756 requirements apply for RADIUS
      messages carrying Key-Response Attribute(s).  Implementations of
      this specification MUST support IPsec along with IKEv2 for key
      management.  IPsec ESP with a non-null transform MUST be
      supported, and IPsec ESP with a non-null encryption transform and
      authentication support is necessary to provide per-packet
      confidentiality, authentication, integrity and replay protection.


  This requirement imposes a heavy burden on any implementation of this
proposal.  Most existing RADIUS EAP deployments do not use IPSec as a
transport layer.  I also question the necessity for exposing the DSRK
"in the clear" to all parties in the AAA conversation.

  i.e. in a proxy environment, entities who transport the traffic do NOT
request the key, but can see it "in the clear".  Not only that, but they
can modify the key without detection, as the key is not authenticated.
This issue is not discussed in the security section.

  It would also appear to be a fatal flaw in this proposal: keys being
exposed to entities that don't need to see the key, and lack of
integrity checks on the keys themselves.

  I question why the visited *network* needs the DSRK, as opposed to the
visited *NAS*.  This document does not discuss any use-cases or
requirements that would make this distinction clear.

  From what I see, only the NAS requires access to any keying material.
 For security, we can presume that the keys are opaque to everyone on
the network other than the user and the home server which authenticates
that user.  Anyone else needing access to those keys can prove their
need to either the user, or to the home server.  And in general, no one
needs to get the key from the home server,

  Since the NAS is already in direct contact with the user, it becomes
clear that the NAS can ask the user how to interpret any keying material
it has.  Since that keying material is opaque to everyone else, there is
no security issue with it being exposed, because it has no useful
information.  Since that keying material is opaque, anyone and everyone
with access to it can cache it.

  See the following message for a short exposition of the concepts
outlined above:

http://ops.ietf.org/lists/radiusext/2007/msg01001.html

  That proposal would seem to meet the requirements outlined for this
document, from what I can understand.  (The requirements and use-cases
outlined here are unclear).  That proposal can be modified to include
key lifetime, if necessary.  That proposal avoids all of the security
issues inherent in this design.

  For this proposal to move forward, it needs to have clearer use-cases
and requirements.  And it needs to address the security issues that are
currently fatal flaws.

  Alan DeKok.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>


Envelope-to: [e-mail]
Delivery-date: Thu, 03 Jan 2008 04:15:30 +0000
Message-ID: <[e-mail]>
Date: Thu, 03 Jan 2008 05:13:10 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Glen Zorn <[e-mail]>
CC: [e-mail]
Subject: Re: Questions on modified Extended Attribute format?
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Glen Zorn wrote:

> As I said, put that way or any other way you like, ANY change is
> incompatible with existing deployments.  If one were to add a new "standard"
> attribute (in the old format or the proposed VSA-like format or any other)
> it would be incompatible with existing deployments.

  That isn't the point.  Everyone accepts that implementations have to
be updated to handle new standards.  One of the major efforts in RADIUS
has been to maintain backwards compatibility with existing deployments.

  i.e. if a product doesn't implement the new standard, it can still
communicate with products that do implement that standard.

  This proposal breaks that completely.  It will be perfectly legal for
implementations of your proposal to put ALL RADIUS attributes as
grouped, inside of an "extended attribute".  Any NAS that receives such
a response will get a packet containing *nothing* but VSA's.  It will
then decide that there is nothing in the packet that it recognizes, and
will fail.

  i.e. your proposal creates a new protocol that is incompatible with
legacy RADIUS.

> Actually, while the timeframe was long, the discussion wasn't: I've only
> received a couple of comments on it in the last months.  It _did_ take an
> inordinate amount of time to reject the 'Diameterization' of RADIUS,
> though...

  This proposal is no better.  It's worse in many respects.

  Alan DeKok.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>