Fwd: Re: Questions on TCP port usage for RADIUS/TLS

[Stefan Winter <[e-mail]>]

  Hi,

forwarding one response from an implementor:

Stefan

---------------------------------

 >** As an implementor, do you think changing the spec towards three
 >separate ports is reasonable, and do you think you would adapt your
 >implementation? **

I'm relatively indifferent to this point.  Since we already monitor
different ports for RADIUS over UDP, listening on one port more or
less via TCP does not make a big difference for us.

 >** If you had to choose between the aforementioned decision points a) or
 >b) , which one would you prefer as an implementor? **

I'd rather prefer separate ports for TCP and TLS traffic.  What is
described as 'application-level multiplexing' would require us to
either implement some sort of non-destructive read from the port
or a sort of 'filter/dispatcher' between the TCP connection and
the TLS stack (which communicates over a given file structure in our
OS) - both of which would required significant effort.

---------------------------------

--
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, 22 Dec 2010 07:18:14 +0000
Message-ID: <[e-mail]>
Date: Wed, 22 Dec 2010 08:17:09 +0100
From: Stefan Winter <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Fwd: Re: Questions on TCP port usage for RADIUS/TLS
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

  Hi,

forwarding one response from an implementor:

Stefan

---------------------------------

 >** As an implementor, do you think changing the spec towards three
 >separate ports is reasonable, and do you think you would adapt your
 >implementation? **

I'm relatively indifferent to this point.  Since we already monitor
different ports for RADIUS over UDP, listening on one port more or
less via TCP does not make a big difference for us.

 >** If you had to choose between the aforementioned decision points a) or
 >b) , which one would you prefer as an implementor? **

I'd rather prefer separate ports for TCP and TLS traffic.  What is
described as 'application-level multiplexing' would require us to
either implement some sort of non-destructive read from the port
or a sort of 'filter/dispatcher' between the TCP connection and
the TLS stack (which communicates over a given file structure in our
OS) - both of which would required significant effort.

---------------------------------

--
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, 20 Dec 2010 22:17:53 +0000
From: Mike McCauley <[e-mail]>
Organization: Open System Consultants
To: Alan DeKok <[e-mail]>
Subject: Re: Questions on TCP port usage for RADIUS/TLS
Date: Tue, 21 Dec 2010 08:16:57 +1000
User-Agent: KMail/1.9.10
Cc: Stefan Winter <[e-mail]>, "[e-mail]" <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <[e-mail]>

Hi,

I agree with Alan on all points.

Cheers.

On Tuesday 21 December 2010 02:02:52 am Alan DeKok wrote:
> Stefan Winter wrote:
> > So, there is a good reasoning on why three distinct ports would make
> > sense. The only problem is: none of the existing implementations does it
> > that way; so there is no running code yet. The question thus is:
>
>   IIRC, the implementations are capable of listening on multiple ports
> at the same time.  This allows then to listen on 3 ports, even if they
> *also* accept all packet codes on each of those ports.
>
> > ** As an implementor, do you think changing the spec towards three
> > separate ports is reasonable, and do you think you would adapt your
> > implementation? **
>
>   I prefer fewer ports.  Adapting the implementation is easier than
> adapting the spec. :)
>
> > ** If you had to choose between the aforementioned decision points a) or
> > b) , which one would you prefer as an implementor? **
>
>   I'd prefer to re-use TCP/1812, TCP/1813, and TCP/3699 for TLS.
>
>   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/>



-- 
Mike McCauley                               [e-mail]
Open System Consultants Pty. Ltd
9 Bulbul Place Currumbin Waters QLD 4223 Australia   http://www.open.com.au
Phone [phone]                       Fax   [phone]

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.

--
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, 20 Dec 2010 16:04:06 +0000
Message-ID: <[e-mail]>
Date: Mon, 20 Dec 2010 17:02:52 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Stefan Winter <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: Questions on TCP port usage for RADIUS/TLS
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

Stefan Winter wrote:
> So, there is a good reasoning on why three distinct ports would make
> sense. The only problem is: none of the existing implementations does it
> that way; so there is no running code yet. The question thus is:

  IIRC, the implementations are capable of listening on multiple ports
at the same time.  This allows then to listen on 3 ports, even if they
*also* accept all packet codes on each of those ports.

> ** As an implementor, do you think changing the spec towards three
> separate ports is reasonable, and do you think you would adapt your
> implementation? **

  I prefer fewer ports.  Adapting the implementation is easier than
adapting the spec. :)

> ** If you had to choose between the aforementioned decision points a) or
> b) , which one would you prefer as an implementor? **

  I'd prefer to re-use TCP/1812, TCP/1813, and TCP/3699 for TLS.

  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: Sat, 18 Dec 2010 20:32:31 +0000
Message-ID: <[e-mail]>
Date: Sat, 18 Dec 2010 21:31:48 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Dan Harkins <[e-mail]>
CC: 'radext mailing list' <[e-mail]>
Subject: Re: Review of draft-zorn-radius-keywrap
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Dan Harkins wrote:
>   I am not attempting to impress you, just to inform you. AES Key Wrap
> was not "invented solely for this specification".

  That's a straw man: quoting text out of context.

> It was developed by
> NIST and published in November of 2001. It has widespread use and has
> received cryptographic analysis. These statements are true whether the
> draft makes mention of them or not.

  It might be useful for the draft to reference the cryptographic method
it's using.  Right now, it doesn't even claim to be implementing the
keywrap method.

  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: Sat, 18 Dec 2010 19:25:18 +0000
Message-ID: <[e-mail]>
Date: Sat, 18 Dec 2010 11:24:17 -0800 (PST)
Subject: Re: Review of draft-zorn-radius-keywrap
From: "Dan Harkins" <[e-mail]>
To: "Alan DeKok" <[e-mail]>
Cc: "Dan Harkins" <[e-mail]>, "'radext mailing list'" <[e-mail]>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit

  Alan,

  I am not attempting to impress you, just to inform you. AES Key Wrap
was not "invented solely for this specification". It was developed by
NIST and published in November of 2001. It has widespread use and has
received cryptographic analysis. These statements are true whether the
draft makes mention of them or not.

  Dan.

On Sat, December 18, 2010 4:22 am, Alan DeKok wrote:
> Dan Harkins wrote:
>>   Neither AES Key Wrap nor (D)TLS are "signature methods". AES Key Wrap
>> is providing an integrity check and confidentiality only on a random
>> key.
>
>   The document contains a Message-Authentication-Code attribute, which
> is defined as:
>
>    This Attribute MAY be used to "sign" messages ...
>
>   The following text describes an "ad hoc" method for signing packets.
> It is not based on keywrap.
>
>   Perhaps you haven't read the document, or you didn't notice the pages
> of text talking about a new packet signature method?
>
>> This technique is now new; it's used in 802.11 (you should note that
>> the draft in question pre-dates the "guidelines" document).
>
>   I'm suitably impressed with this irrelevant fact.
>
>>   AES Key Wrap has received quite a bit of analysis. There is a very
>> good critique of it in "Deterministic Authenticated Encryption: A
>> Provable Security Treatment of the Key Wrap Problem" by Rogaway and
>> Shrimpton available at:
>>
>>             http://web.cecs.pdx.edu/~teshrim/keywrap.pdf
>
>   Which is not referenced anywhere in the document.
>
>   In fact, there is *no* reference in the document to any security
> analysis, origin, or history of the "keywrap" method.  The *only*
> reference to "keywrap" is in the document title.
>
>   Given the document *on its face*, the authors have given us every
> reason to believe that the cryptographic methods described in it were
> invented solely for this specification.
>
>   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/>
>



--
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, 18 Dec 2010 12:23:16 +0000
Message-ID: <[e-mail]>
Date: Sat, 18 Dec 2010 13:22:09 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Dan Harkins <[e-mail]>
CC: 'radext mailing list' <[e-mail]>
Subject: Re: Review of draft-zorn-radius-keywrap
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Dan Harkins wrote:
>   Neither AES Key Wrap nor (D)TLS are "signature methods". AES Key Wrap
> is providing an integrity check and confidentiality only on a random key.

  The document contains a Message-Authentication-Code attribute, which
is defined as:

   This Attribute MAY be used to "sign" messages ...

  The following text describes an "ad hoc" method for signing packets.
It is not based on keywrap.

  Perhaps you haven't read the document, or you didn't notice the pages
of text talking about a new packet signature method?

> This technique is now new; it's used in 802.11 (you should note that
> the draft in question pre-dates the "guidelines" document).

  I'm suitably impressed with this irrelevant fact.

>   AES Key Wrap has received quite a bit of analysis. There is a very
> good critique of it in "Deterministic Authenticated Encryption: A
> Provable Security Treatment of the Key Wrap Problem" by Rogaway and
> Shrimpton available at:
> 
>             http://web.cecs.pdx.edu/~teshrim/keywrap.pdf

  Which is not referenced anywhere in the document.

  In fact, there is *no* reference in the document to any security
analysis, origin, or history of the "keywrap" method.  The *only*
reference to "keywrap" is in the document title.

  Given the document *on its face*, the authors have given us every
reason to believe that the cryptographic methods described in it were
invented solely for this specification.

  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, 17 Dec 2010 21:32:51 +0000
Message-ID: <[e-mail]>
Date: Fri, 17 Dec 2010 13:31:48 -0800 (PST)
Subject: Re: Review of draft-zorn-radius-keywrap
From: "Dan Harkins" <[e-mail]>
To: "Alan DeKok" <[e-mail]>
Cc: "'radext mailing list'" <[e-mail]>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit

  Hello,

On Tue, December 14, 2010 8:32 am, Alan DeKok wrote:
>   This is a review of the draft-zorn-radius-keywrap document.
>
>   First off, as co-author of the "Guidelines" document, most of the
> comments below come straight from that document.
>
>   The keywrap document defines a new RADIUS packet signature method, at
> a time when TLS and DTLS transport have been worked on for a number of
> years.  This new signature method has had little security analysis, in
> contrast to TLS.

  Neither AES Key Wrap nor (D)TLS are "signature methods". AES Key Wrap
is providing an integrity check and confidentiality only on a random key.
This technique is now new; it's used in 802.11 (you should note that
the draft in question pre-dates the "guidelines" document).

  AES Key Wrap has received quite a bit of analysis. There is a very
good critique of it in "Deterministic Authenticated Encryption: A
Provable Security Treatment of the Key Wrap Problem" by Rogaway and
Shrimpton available at:

            http://web.cecs.pdx.edu/~teshrim/keywrap.pdf

  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: Tue, 14 Dec 2010 20:17:59 +0000
Message-ID: <[e-mail]>
Date: Tue, 14 Dec 2010 21:17:08 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: "Romascanu, Dan (Dan)" <[e-mail]>
CC: radext mailing list <[e-mail]>
Subject: Re: Review of draft-zorn-radius-keywrap
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Romascanu, Dan (Dan) wrote:
> So, trying to make sure that I understand your point, the document could
> be possibly OK as a definition of a one vendor set of extensions but
> would fail some of the criteria of the guidelines document for
> multi-vendor usage. 

  I would replace "some" with "nearly all".

  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, 14 Dec 2010 17:22:44 +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: Review of draft-zorn-radius-keywrap
Date: Tue, 14 Dec 2010 18:22:17 +0100
Message-ID: <[e-mail]>
Thread-Topic: Review of draft-zorn-radius-keywrap
Thread-Index: AcubspupZGOcTbrvThakmnNa4FIvsQAAE9dQ
From: "Romascanu, Dan (Dan)" <[e-mail]>
To: "Alan DeKok" <[e-mail]>
Cc: "radext mailing list" <[e-mail]>

So, trying to make sure that I understand your point, the document could
be possibly OK as a definition of a one vendor set of extensions but
would fail some of the criteria of the guidelines document for
multi-vendor usage.=20

Dan

 =20

> -----Original Message-----
> From: Alan DeKok [mailto:[e-mail]]=20
> Sent: Tuesday, December 14, 2010 7:16 PM
> To: Romascanu, Dan (Dan)
> Cc: radext mailing list
> Subject: Re: Review of draft-zorn-radius-keywrap
>=20
> Romascanu, Dan (Dan) wrote:
> > I would like to make a clarification - draft-zorn-radius-keywrap is=20
> > and Independent Stream submission. An RFC document that=20
> would result=20
> > from a possible approval of this document would not be an IETF=20
> > document, but an Independent Submission Stream RFC. Not all=20
> RFCs are=20
> > IETF documents. See RFC 4844 section 5 for definitions of=20
> the different RFC streams.
>=20
>   Sure.  The following text from Section 3.3.1 still applies, though:
>=20
>    The design and specification of VSAs for multi-vendor=20
> usage SHOULD be
>    undertaken with the same level of care as standard RADIUS=20
> attributes.
>    Specifically, the provisions of this document that apply=20
> to standard
>    RADIUS attributes also apply to VSAs for multi-vendor usage.
>=20
>   The document does not meet that criteria.
>=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: Tue, 14 Dec 2010 17:16:37 +0000
Message-ID: <[e-mail]>
Date: Tue, 14 Dec 2010 18:16:07 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: "Romascanu, Dan (Dan)" <[e-mail]>
CC: radext mailing list <[e-mail]>
Subject: Re: Review of draft-zorn-radius-keywrap
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Romascanu, Dan (Dan) wrote:
> I would like to make a clarification - draft-zorn-radius-keywrap is and
> Independent Stream submission. An RFC document that would result from a
> possible approval of this document would not be an IETF document, but an
> Independent Submission Stream RFC. Not all RFCs are IETF documents. See
> RFC 4844 section 5 for definitions of the different RFC streams. 

  Sure.  The following text from Section 3.3.1 still applies, though:

   The design and specification of VSAs for multi-vendor usage SHOULD be
   undertaken with the same level of care as standard RADIUS attributes.
   Specifically, the provisions of this document that apply to standard
   RADIUS attributes also apply to VSAs for multi-vendor usage.

  The document does not meet that criteria.

  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, 14 Dec 2010 17:03:32 +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: Review of draft-zorn-radius-keywrap
Date: Tue, 14 Dec 2010 18:03:01 +0100
Message-ID: <[e-mail]>
Thread-Topic: Review of draft-zorn-radius-keywrap
Thread-Index: AcubrNMScP9xbe8ZT0auuacbi/F7swAAko7g
From: "Romascanu, Dan (Dan)" <[e-mail]>
To: "Alan DeKok" <[e-mail]>, "radext mailing list" <[e-mail]>

Alan,

Thanks for your review.=20

I would like to make a clarification - draft-zorn-radius-keywrap is and
Independent Stream submission. An RFC document that would result from a
possible approval of this document would not be an IETF document, but an
Independent Submission Stream RFC. Not all RFCs are IETF documents. See
RFC 4844 section 5 for definitions of the different RFC streams.=20

Dan


> -----Original Message-----
> From: [e-mail]=20
> [mailto:[e-mail]] On Behalf Of Alan DeKok
> Sent: Tuesday, December 14, 2010 6:32 PM
> To: 'radext mailing list'
> Subject: Review of draft-zorn-radius-keywrap
>=20
>=20
>   This is a review of the draft-zorn-radius-keywrap document.
>=20
>   First off, as co-author of the "Guidelines" document, most=20
> of the comments below come straight from that document.
>=20
>   The keywrap document defines a new RADIUS packet signature=20
> method, at a time when TLS and DTLS transport have been=20
> worked on for a number of years.  This new signature method=20
> has had little security analysis, in contrast to TLS.
>=20
>   The documents defines a multi-field "text" attribute, which=20
> contradicts Section 3.2.3 of the guidelines document.  It=20
> does so withing a Vendor-Specific space, which is permitted=20
> by the documen.
> i.e. vendors can do anything they want in their space.
>=20
>   However, anything that's done in the Vendor-Specific space=20
> does not need to be published as an IETF document.  So I'm a=20
> little unsure as to the purpose of this document.  If it's a=20
> vendor extension, there's no need for an IETF document.  If=20
> it's for use in the wider community, it should follow Section=20
> 3.3.1 of the guidelines document:
>=20
>    The design and specification of VSAs for multi-vendor=20
> usage SHOULD be
>    undertaken with the same level of care as standard RADIUS=20
> attributes.
>    Specifically, the provisions of this document that apply=20
> to standard
>    RADIUS attributes also apply to VSAs for multi-vendor usage.
>=20
>   All in all, the draft contradicts the guidelines in pretty=20
> much every respect.
>=20
>   Alan DeKok.
>=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, 14 Dec 2010 16:54:45 +0000
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="_84db86b4-750d-49a3-9458-fced07eeec38_"
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Review of draft-zorn-radius-keywrap
Date: Tue, 14 Dec 2010 08:54:15 -0800
MIME-Version: 1.0

--_84db86b4-750d-49a3-9458-fced07eeec38_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


There are two major issues remaining in this document.

One issue is that in a number of places=2C the document appears to=20
contradict IETF standards track documents.=20

Examples:

Section 3.1

      If the client requires the use of the Keying-Material Attribute
      for keying material delivery and it is not present in the Access-
      Accept or Access-Challenge message=2C the client MAY ignore the
      message in question and end the user session.

[BA] Presumbly the MAY is included here for security reasons=2C such as pre=
venting
the client from accepting a downlevel key from a server from which it has
previously received keying material described in this document=2C thus prev=
enting
spoofing in the event that the RADIUS shared secret (or MD5) is compromised=
.
However=2C in such a situation the key material itself would be compromised=
=2C
so that some sort of warning should probably be raised.=20

My recommendation is that this be rewritten to state the considerations=20
underlying the MAY=2C as well as recommended behavior in line with RFC 2865
Section 5.26=2C which states:

      Clients which do not receive desired vendor-specific information
      SHOULD make an attempt to operate without it=2C although they may do
      so (and report they are doing so) in a degraded mode.

RFC 2865 is written this way to prevent the creation of proprietary RADIUS
implementations that require the presence of vendor-specific information.=20

Section 3.3

      Any packet that contains an instance of the Message-
      Authentication-Code Attribute SHOULD NOT contain an instance of
      the Message-Authenticator Attribute [RFC3579].

[BA] Since the Message-Authenticator Attribute is mandated by RFC 3579=2C
this represents a contradiction.  My recommendation would be to remove
this sentence=2C and require that the key used in computing the=20
Message-Authentication-Code be cryptographically independent of the
RADIUS shared secret.  That way both attributes can be included without
damage.

Section 5

   It is RECOMMENDED in this memo that two new keys=2C a key encrypting
   key and a message authentication key=2C be shared by the RADIUS client
   and server.  If implemented=2C these two keys MUST be different from
   each other and SHOULD NOT be based on a password.  These two keys
   SHOULD be cryptographically independent of the RADIUS shared secret
   used in calculating the Response Authenticator [RFC2865]=2C Request
   Authenticator [RFC2866] [RFC5176] and Message-Authenticator Attribute
   [RFC3579]=3B otherwise if the shared secret is broken=2C all is lost.

[BA] I believe that cryptgraphic independence of the RADIUS shared secret
needs to be a MUST=2C since the goal of this document is to provide securit=
y
even in a situation where the RADIUS shared secret could be compromised.=20

Another issue is that there are a number of fields for which "the content=20

of this field is outside the scope of this document." The document

needs to provide enough information on these fields to enable

interoperability.  Currently it is not clear if this is the case.=20



Fields which are not adequately explained include the following:



Section 3.1 Keying-Material



      KEK ID



         The KEK ID field is 16 octets in length and contains an

         identifier for the KEK.  The KEK ID MUST refer to an encryption

         key of a type and length appropriate for use with the algorithm

         specified by the Enc Type field (see above).  This key is used

         to protect the contents of the Data field (below).  Further

         specification of the content of this field is outside the scope

         of this document.



      KM ID



         The KM ID field is 16 octets in length and contains an

         identifier for the contents of the Data field.  The KM ID MAY

         be used by communicating parties to identify the material being

         transmitted.  The combination of App ID and KM ID MUST uniquely

         identify the keying material between the parties utilizing it.

         The KM ID is assumed to be known to the parties that derived

         the keying material.  If the KM ID is not used it is set to 0.

         Further specification of the content of this field is outside

         the scope of this document.



Section 3.3  Message-Authentication-Code



      MAC Key ID



         The MAC Key ID field is 16 octets in length and contains an

         identifier for the key.  The MAC Key ID MUST refer to a key of

         a type and length appropriate for use with the algorithm

         specified by the MAC Type field (see above).  Further

         specification of the content of this field is outside the scope

         of this document.




 		 	   		  =

--_84db86b4-750d-49a3-9458-fced07eeec38_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style><!--
.hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Tahoma
}
--></style>
</head>
<body class=3D'hmmessage'>
There are two major issues remaining in this document.<br><br>One issue is =
that in a number of places=2C the document appears to <br>contradict IETF s=
tandards track documents. <br><br>Examples:<br><br>Section 3.1<br><br>&nbsp=
=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B If the client requires the use of the K=
eying-Material Attribute<br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B for ke=
ying material delivery and it is not present in the Access-<br>&nbsp=3B&nbs=
p=3B&nbsp=3B&nbsp=3B&nbsp=3B Accept or Access-Challenge message=2C the clie=
nt MAY ignore the<br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B message in qu=
estion and end the user session.<br><br>[BA] Presumbly the MAY is included =
here for security reasons=2C such as preventing<br>the client from acceptin=
g a downlevel key from a server from which it has<br>previously received ke=
ying material described in this document=2C thus preventing<br>spoofing in =
the event that the RADIUS shared secret (or MD5) is compromised.<br>However=
=2C in such a situation the key material itself would be compromised=2C<br>=
so that some sort of warning should probably be raised. <br><br>My recommen=
dation is that this be rewritten to state the considerations <br>underlying=
 the MAY=2C as well as recommended behavior in line with RFC 2865<br>Sectio=
n 5.26=2C which states:<br><br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B Cli=
ents which do not receive desired vendor-specific information<br>&nbsp=3B&n=
bsp=3B&nbsp=3B&nbsp=3B&nbsp=3B SHOULD make an attempt to operate without it=
=2C although they may do<br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B so (an=
d report they are doing so) in a degraded mode.<br><br>RFC 2865 is written =
this way to prevent the creation of proprietary RADIUS<br>implementations t=
hat require the presence of vendor-specific information. <br><br>Section 3.=
3<br><br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B Any packet that contains =
an instance of the Message-<br>&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B Aut=
hentication-Code Attribute SHOULD NOT contain an instance of<br>&nbsp=3B&nb=
sp=3B&nbsp=3B&nbsp=3B&nbsp=3B the Message-Authenticator Attribute [RFC3579]=
.<br><br>[BA] Since the Message-Authenticator Attribute is mandated by RFC =
3579=2C<br>this represents a contradiction.&nbsp=3B My recommendation would=
 be to remove<br>this sentence=2C and require that the key used in computin=
g the <br>Message-Authentication-Code be cryptographically independent of t=
he<br>RADIUS shared secret.&nbsp=3B That way both attributes can be include=
d without<br>damage.<br><br>Section 5<br><br>&nbsp=3B&nbsp=3B It is RECOMME=
NDED in this memo that two new keys=2C a key encrypting<br>&nbsp=3B&nbsp=3B=
 key and a message authentication key=2C be shared by the RADIUS client<br>=
&nbsp=3B&nbsp=3B and server.&nbsp=3B If implemented=2C these two keys MUST =
be different from<br>&nbsp=3B&nbsp=3B each other and SHOULD NOT be based on=
 a password.&nbsp=3B These two keys<br>&nbsp=3B&nbsp=3B SHOULD be cryptogra=
phically independent of the RADIUS shared secret<br>&nbsp=3B&nbsp=3B used i=
n calculating the Response Authenticator [RFC2865]=2C Request<br>&nbsp=3B&n=
bsp=3B Authenticator [RFC2866] [RFC5176] and Message-Authenticator Attribut=
e<br>&nbsp=3B&nbsp=3B [RFC3579]=3B otherwise if the shared secret is broken=
=2C all is lost.<br><br>[BA] I believe that cryptgraphic independence of th=
e RADIUS shared secret<br>needs to be a MUST=2C since the goal of this docu=
ment is to provide security<br>even in a situation where the RADIUS shared =
secret could be compromised. <br><br>Another issue is that there are a numb=
er of fields for which "the content <br>
of this field is outside the scope of this document." The document<br>
needs to provide enough information on these fields to enable<br>
interoperability.&nbsp=3B Currently it is not clear if this is the case. <b=
r>
<br>
Fields which are not adequately explained include the following:<br>
<br>
Section 3.1 Keying-Material<br>
<br>
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B KEK ID<br>
<br>
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B The KEK ID=
 field is 16 octets in length and contains an<br>
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B identifier=
 for the KEK.&nbsp=3B The KEK ID MUST refer to an encryption<br>
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B key of a t=
ype and length appropriate for use with the algorithm<br>
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B specified =
by the Enc Type field (see above).&nbsp=3B This key is used<br>
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B to protect=
 the contents of the Data field (below).&nbsp=3B Further<br>
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B specificat=
ion of the content of this field is outside the scope<br>
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B of this do=
cument.<br>
<br>
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B KM ID<br>
<br>
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B The KM ID =
field is 16 octets in length and contains an<br>
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B identifier=
 for the contents of the Data field.&nbsp=3B The KM ID MAY<br>
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B be used by=
 communicating parties to identify the material being<br>
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B transmitte=
d.&nbsp=3B The combination of App ID and KM ID MUST uniquely<br>
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B identify t=
he keying material between the parties utilizing it.<br>
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B The KM ID =
is assumed to be known to the parties that derived<br>
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B the keying=
 material.&nbsp=3B If the KM ID is not used it is set to 0.<br>
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B Further sp=
ecification of the content of this field is outside<br>
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B the scope =
of this document.<br>
<br>
Section 3.3&nbsp=3B Message-Authentication-Code<br>
<br>
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B MAC Key ID<br>
<br>
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B The MAC Ke=
y ID field is 16 octets in length and contains an<br>
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B identifier=
 for the key.&nbsp=3B The MAC Key ID MUST refer to a key of<br>
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B a type and=
 length appropriate for use with the algorithm<br>
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B specified =
by the MAC Type field (see above).&nbsp=3B Further<br>
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B specificat=
ion of the content of this field is outside the scope<br>
&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B&nbsp=3B of this do=
cument.<br>
<br>
<br> 		 	   		  </body>
</html>=

--_84db86b4-750d-49a3-9458-fced07eeec38_--

--
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, 14 Dec 2010 16:33:21 +0000
Message-ID: <[e-mail]>
Date: Tue, 14 Dec 2010 17:32:13 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: 'radext mailing list' <[e-mail]>
Subject: Review of draft-zorn-radius-keywrap
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

  This is a review of the draft-zorn-radius-keywrap document.

  First off, as co-author of the "Guidelines" document, most of the
comments below come straight from that document.

  The keywrap document defines a new RADIUS packet signature method, at
a time when TLS and DTLS transport have been worked on for a number of
years.  This new signature method has had little security analysis, in
contrast to TLS.

  The documents defines a multi-field "text" attribute, which
contradicts Section 3.2.3 of the guidelines document.  It does so
withing a Vendor-Specific space, which is permitted by the documen.
i.e. vendors can do anything they want in their space.

  However, anything that's done in the Vendor-Specific space does not
need to be published as an IETF document.  So I'm a little unsure as to
the purpose of this document.  If it's a vendor extension, there's no
need for an IETF document.  If it's for use in the wider community, it
should follow Section 3.3.1 of the guidelines document:

   The design and specification of VSAs for multi-vendor usage SHOULD be
   undertaken with the same level of care as standard RADIUS attributes.
   Specifically, the provisions of this document that apply to standard
   RADIUS attributes also apply to VSAs for multi-vendor usage.

  All in all, the draft contradicts the guidelines in pretty much every
respect.

  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, 07 Dec 2010 14:17:36 +0000
Message-ID: <[e-mail]>
Date: Tue, 07 Dec 2010 15:16:40 +0100
From: Alan DeKok <[e-mail]>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Bernard Aboba <[e-mail]>
CC: [e-mail]
Subject: Re: General Request for NAS-Port-Type assignments (fwd)
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Bernard Aboba wrote:
> Any thoughts on the proposed NAS-Port-Type assignments?

  There are ~2^32 entries unallocated.  I think we can allocate 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: Tue, 07 Dec 2010 03:33:17 +0000
Message-ID: <[e-mail]>
From: Bernard Aboba <[e-mail]>
To: <[e-mail]>
Subject: General Request for NAS-Port-Type assignments (fwd)
Date: Mon, 6 Dec 2010 22:34:43 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Thread-Index: AcuVtZ+h36kXzET+TByH+82Ad3J1cQACdXKw
Content-Language: en-us

Any thoughts on the proposed NAS-Port-Type assignments?

On Mon Nov 29 20:11:25 2010, amanda.baber wrote:

>
> Can we add these proposed values to the Nas-Port-Type registry?
> 
> Thanks,
> 
> Amanda Baber
> IANA
> 
> 
> ===
> 
> Contact Name :
> Avi Lior
> 
> Contact Email :
> [e-mail]
> 
> Type of Assignment :
> Seeing new Nas-Port-Type values as follows:
> TBD for WIMAX-3GPP-PRIF: WiMAX Pre-Release 8 IWK Function
> TBD for WIMAX-WIFI-IWK: WiMAX WIFI Interworking
> TBD for WIMAX-SFF: Signaling Forwarding Function for LTE/3GPP2.
> TBD for WIMAX-HA-LMA: WiMAX HA and or LMA function.
> TBD for WIMAX-DHCP : WIMAX DCHP service
> TBD for WIMAX-LBS : WiMAX location based service
> TBD for WIMAX-WVS : WiMAX voice service
> 
> Registry :
> NAS-Port-Type (attribute 61) from RADIUS Type Registry
> 
> Description :
> These assignments will allow the RADIUS server to determine the service
> context of the access-request. For example whether the RADIUS message is
> coming from a Signalling Forwarding Function(SFF) or WiMAX voice
> function etc.
> 
> Additional Info :
> Reference specifications are avaialble from WiMAX Forum at the following
> site:
> http://www.wimaxforum.org/




--
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, 01 Dec 2010 15:24:46 +0000
From: "Dave Nelson" <[e-mail]>
To: "'Juergen Schoenwaelder'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: ssh authentication and service authorization questions
Date: Wed, 1 Dec 2010 10:24:29 -0500
Message-ID: <D245C024E0D64E57A6DEFF566F2F5C1C@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcuRaTP8PKd9fSnESKS6tBEuaevyAwAAgAUw

Juergen Schoenwaelder writes...

> The NETCONF WG is not depending on this as far as I can tell.
> It is more that implementors do not know how to implement things
> from the specs we have produced. And I think this is a good reason
> to improve the specs.

Right.

I'll be happy to take a look at the discussion so far and propose some
possible revisions to address the issue of SSH service multiplexing in a
robust fashion.  If the chairs eventually deem that we should work on an
RFC5607bis document, I'll be happy to work on that, too.

My only concern is that we engage some SSH server experts, who can advise us
if we are asking for an interaction between SSH and RADIUS that will be
difficult to implement or deploy.



--
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, 01 Dec 2010 14:43:16 +0000
From: "Dave Nelson" <[e-mail]>
To: "'Juergen Schoenwaelder'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: ssh authentication and service authorization questions
Date: Wed, 1 Dec 2010 09:43:06 -0500
Message-ID: <8320246354A44116AAE115FAB1037D6B@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcuRYsurANbrxYisT8SUVrcfGgZOpQAAjw2Q

Juergen Schoenwaelder writes...
 
> I think it is important to clarify this aspect of RADIUS usage
> with protocols such as SSH. I support someone working on a revision
> of RFC 5607 that clarifies this detail.

Is this something that the NETCONF WG needs in support of its authentication
and authorization work?  I imagine that an RFC5607bis document would be in
scope as a potential RADEXT WG work item, if there is sufficient support for
it.

I could find some time to work on it, if there is support, and would
volunteer to co-author.



--
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, 01 Dec 2010 14:01:47 +0000
From: "Dave Nelson" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: ssh authentication and service authorization questions
Date: Wed, 1 Dec 2010 09:01:11 -0500
Message-ID: <2DB65BD47A414F5EB5A8EDBD3F1B1DDA@NEWTON603>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcuQyamx+K7/cgd+SYyuWFsVJ+IFggAHTtVgAB3EgFA=

Bernard Aboba writes...

> RFC 5607 uses Service-Type=Framed-Management. Presumably
> that would be used in exchanges 1,2.

Not necessarily.  If the SSH service that's ultimately provided over the SSH
session is the terminal service, then Service-Type ought to NAS-Prompt or
Administrative.  Quite frankly the SSH model of multiplexed service delivery
challenges the RADIUS model of hint-and-provision. There's no single
meaningful hint as to the SSH service that can be provided by the RADIUS
client at the time of SSH session establishment.

> Section 6.1 states that the Framed-Management-Protocol
> attribute is used with Service-Type=Framed-Management.
> However, this isn't known until exchange 3 which will need
> to use Service-Type=Authorize-Only.

Right.

> Maybe the solution is just to clarify the Section 6.1 text?

I'd need to go back and look at it in detail, but I agree that RFC 5607
could be extended to handle a multi-round-trip RADIUS authentication and
authorization using Authorize-Only.  Certainly the RADIUS client that is
tied into the SSH implementation would be in a position to know when to send
an Authorize-Only request.  The largest challenge probably lies with the SSH
implementation, to revise it such that it calls the RADIUS client again
after session establishment but before service establishment.

Alan DeKok writes...

>   Or use Service-Type = Authorize-Only?
> 
>   It's intended for CoA, but there's no technical reason it couldn't be
> used here.
> 
>   i.e.
> 
> 1,2) Access-Request for initial session (user + password)
>      Access-Accept contains State
> 
> 3)  For each service:
> 
>        Access-Request + User-Name + State + Authorize-Only + ...
>        ...
> 
>   The State attribute ties the later Access-Requests to the first one.
> The RADIUS server can authorize individual services, based on their
> connection with the initial Access-Request.

Yes, I agree that this method could be used to authorize multiple SSH
services multiplexed over a single SSH session.



--
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/>