Subject: [AAA-DOCTORS] Fwd: New Version Notification - draft-ietf-softwire-6rd-radius-attrib-08.txt

From: Benoit Claise <[email-masked]>
Date: Mon, 10 Dec 2012 08:56:06 +0100

AAA doctors,

Here is a new draft version.
Let us know if your points have been addressed.

Regards, Benoit

-------- Original Message --------
Subject: 	New Version Notification - 
draft-ietf-softwire-6rd-radius-attrib-08.txt
Date: 	Sun, 09 Dec 2012 23:15:03 -0800
From: 	[email-masked]
To: 	[email-masked], 
[email-masked], 
[email-masked], [email-masked], [email-masked], 
[email-masked]

A new version (-08) has been submitted for draft-ietf-softwire-6rd-radius-attrib:
http://www.ietf.org/internet-drafts/draft-ietf-softwire-6rd-radius-attrib-08.txt

Sub state has been changed to AD Followup from Revised ID Needed

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-6rd-radius-attrib-08

IETF Secretariat.

---

From: Glen Zorn <[email-masked]>
Date: Mon, 10 Dec 2012 18:00:19 +0700

> Let us know if your points have been addressed.

There are still a whole bunch of English language usage errors, too many 
to be acceptable, IMHO.  My biggest question, though, is who or what is 
being authenticated & how in Section 3.  What value is sent in the 
User-Password or CHAP-Password (one of which is required by RFC 2865)?  
Or is EAP being used?  AFAICT, the only data available to the RADIUS 
client is what came in the DHCPDISCOVER packet, so how does that map to 
User-Name & credentials?

> _______________________________________________
> AAA-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aaa-doctors

---

From: Glen Zorn <[email-masked]>
Date: Tue, 11 Dec 2012 14:46:36 +0700

On 12/11/2012 01:55 PM, Sheng Jiang wrote:
>> My biggest question,  though, is who or what is being authenticated
 >> & how in Section 3. What value is sent in the User-Password or
 >> CHAP-Password (one of which is required by RFC 2865)? Or is EAP
 >> being used? AFAICT, the only data available to the RADIUS client
 >> is what came in the DHCPDISCOVER packet, so how does that map to
 >> User-Name & credentials?
 >
 > Hi, Glen,
 >
 > The only reason we did not define this is because it is "normal
 > authentication", not 6rd specific. The detailed can be found in RFC
 > 4014 "Remote Authentication Dial-In User Service (RADIUS) Attributes
 > Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay
 > Agent Information Option". We will add this into reference.

  1. RFC 4014 describes a suboption of the DHCP Relay Agent Information 
Option but I can't find any mention of a relay agent in your draft.
  2. I don't really understand what you mean by "normal" 
authentication.  The RADIUS Attributes Suboption was apparently designed 
to carry RADIUS attributes (populated from an IEEE 802.1X exchange) from 
a relay agent to a DHCP server.  Are you assuming that 802.1X will be 
used for user authentication?  RFC 5969 doesn't mention .1X, nor does 
your draft.

...

---

From: Glen Zorn <[email-masked]>
Date: Tue, 11 Dec 2012 16:02:43 +0700

On 12/11/2012 03:29 PM, Sheng Jiang wrote:
>>>> My biggest  question, though, is who or what is being
 >>>> authenticated & how in Section 3. What value is sent in the
 >>>> User-Password or CHAP-Password (one of which is required by RFC
 >>>> 2865)? Or is EAP being used? AFAICT, the only data available to
 >>>> the RADIUS client is what came in the DHCPDISCOVER packet, so
 >>>> how does that map to User-Name & credentials?
 >>>
 >>> Hi, Glen,
 >>>
 >>> authentication", not 6rd specific. The detailed can be found in
 >>> RFC 4014 "Remote Authentication Dial-In User Service (RADIUS)
 >>> Attributes Suboption for the Dynamic Host Configuration Protocol
 >>> (DHCP) Relay Agent Information Option". We will add this into
 >>> reference.
 >>
 >> 1. RFC 4014 describes a suboption of the DHCP Relay Agent
 >> Information Option but I can't find any mention of a relay agent in
 >> your draft.
 >
 > Hi, Glen,
 >
 > Thanks so much for your reply. Now I understand your question.
 >
 > You are right, we should define more detail BNG behavior in the
 > authentication procedure.
 >
 > Could the below new text address your question?

Closer, but there is still the matter of credentials: what value is in 
the User-Password (or equivalent) Attribute?

>
 >
 > New:
 >
 > When the BNG receives the DHCPDISCOVER, it initiates a Radius
 > Access-Request message, in which the User-Name attribute is filled by
 > 6rd CE MAC address, to the Radius server, requesting authentication
 > as defined in [RFC2865] and IPv6-6rd-Configuration attribute, in the
 > desired attribute list.
 >
 > Best regards,
 >
 > Sheng
 >
 >> authentication. The RADIUS Attributes Suboption was apparently
 >> designed to carry RADIUS attributes (populated from an IEEE 802.1X
 >> exchange) from a relay agent to a DHCP server. Are you assuming
 >> that 802.1X will be used for user authentication? RFC 5969 doesn't
 >> mention .1X, nor does your draft.
 >>
 >> ...
 >

---

From: Glen Zorn <[email-masked]>
Date: Tue, 11 Dec 2012 16:50:28 +0700

On 12/11/2012 04:15 PM, Sheng Jiang wrote:
>
>> -----Original Message-----
>> From: Glen Zorn [mailto:[email-masked]]
>> Sent: Tuesday, December 11, 2012 5:03 PM
>> To: Sheng Jiang
>> Cc: Glen Zorn; Benoit Claise; [email-masked];
>> [email-masked]; Ralph Droms
>> Subject: Re: [AAA-DOCTORS] Fwd: New Version Notification -
> My guess is the user-password could be the same along different users. So, it could be pre-configured in DHCP server. So, the below is new refined text:
>
> When the BNG receives the DHCPDISCOVER, it initiates a Radius Access-Request message, in which the User-Name attribute is filled by the 6rd CE MAC address to the Radius server and the User-password attribute is filled by the shared 6rd password that has been preconfigured on the DHCP server, requesting authentication as defined in [RFC2865] and IPv6-6rd-Configuration attribute, defined in the next Section, in the desired attribute list.

OK, from your draft and this conversation, it appears to me that what yo 
really want to do is send an Access-Request message containing a 
Service-Type Attribute containing the value 10 (Call Check) and an 
instance of the IPv6-6rd-Configuration Attribute as a hint.  I believe 
that does what you want & it doesn't break any RADIUS rules of which I 
am aware.  I'm not sure if the User-Password Attribute is required in 
this case -- probably shouldn't be.  Just do that in every case i.e., 
delete the second scenario altogether. Very simple.

>
> Many thanks and best regards,
>
> Sheng
>
>>>
>>> New:
>>>

---

From: Glen Zorn <[email-masked]>
Date: Tue, 11 Dec 2012 17:17:23 +0700

On 12/11/2012 05:02 PM, Sheng Jiang wrote:

>>>> From: Glen Zorn  [mailto:[email-masked]] Sent: Tuesday,
 >>>> December 11, 2012 5:03 PM To: Sheng Jiang Cc: Glen Zorn; Benoit
 >>>> Claise; [email-masked];
 >>>> [email-masked]; Ralph
 >>>> Droms Subject: Re: [AAA-DOCTORS] Fwd: New Version Notification
 >>>> - draft-ietf-softwire-6rd-radius-attrib-08.txt
 >>>>
 >>>>>>>> authenticated & how in Section 3. What value is sent in
 >>>>>>>> the User-Password or CHAP-Password (one of which is
 >>>>>>>> required by RFC 2865)? Or is EAP being used? AFAICT,
 >>>>>>>> the only data available to the RADIUS client is what
 >>>>>>>> came in the DHCPDISCOVER packet, so how does that map
 >>>>>>>> to User-Name & credentials?
 >>>>>>> Hi, Glen,
 >>>>>>>
 >>>>>>> The only reason we did not define this is because it is
 >>>>>>> "normal authentication", not 6rd specific. The detailed
 >>>>>>> can be found in RFC 4014 "Remote Authentication Dial-In
 >>>>>>> User Service (RADIUS) Attributes Suboption for the
 >>>>>>> Dynamic Host Configuration Protocol (DHCP) Relay Agent
 >>>>>>> Information Option". We will add this into reference.
 >>>>>> Information Option but I can't find any mention of a relay
 >>>>>> agent in your draft.
 >>>>> Hi, Glen,
 >>>>>
 >>>>> You are right, we should define more detail BNG behavior in
 >>>>> the authentication procedure.
 >>>>>
 >>>> Closer, but there is still the matter of credentials: what
 >>>> value is in the User-Password (or equivalent) Attribute?
 >>> My guess is the user-password could be the same along different
 >>> users. So,
 >> it could be pre-configured in DHCP server. So, the below is new
 >> refined text:
 >>>
 >> Access-Request message, in which the User-Name attribute is filled
 >> by the 6rd CE MAC address to the Radius server and the
 >> User-password attribute is filled by the shared 6rd password that
 >> has been preconfigured on the DHCP server, requesting
 >> authentication as defined in [RFC2865] and IPv6-6rd-Configuration
 >> attribute, defined in the next Section, in the desired attribute
 >> list.
 >>
 >> OK, from your draft and this conversation, it appears to me that
 >> what yo really want to do is send an Access-Request message
 >> containing a Service-Type Attribute containing the value 10 (Call
 >> Check) and an instance of the IPv6-6rd-Configuration Attribute as a
 >> hint. I believe that does what you want & it doesn't break any
 >> RADIUS rules of which I am aware. I'm not sure if the
 >> User-Password Attribute is required in this case -- probably
 >> shouldn't be. Just do that in every case i.e., delete the second
 >> scenario altogether. Very simple.
 >
 > Hi, Glen,
 >
 > That's what we had in 07 version as quoted below. But get DISCUSS
 > from Security AD.
 >
 > 07 version, "the Access-Request packet contains a Service-Type
 > attribute with the value Call-Check (10)."
 >
 > DISCUSS from Sec AD:
 >
 > 3. A RADIUS message used for call-check does not contain any
 > information that would authenticate the request and is therefore
 > susceptible to forgery. Therefore, RADIUS messages using the 6rd
 > attribute MUST include a message-authenticator attribute or another
 > attribute that is capable of authenticating the RAIDUS packet.
 >
 > The "Call Check" Service-Type was designed for situations where
 > authorization can be determined via the Called-Station-Id or
 > Calling-Station-Id attributes, which originally contained telephone
 > numbers. In RFC 3580, Called/Calling-Station-Id could also contain a
 > MAC address, but the principle was similar -- an unique
 > (non-authenticated) identifier which could be used to determine
 > whether a call was authorized.
 >
 > However, this draft does not say anything about use of the
 > Calling-Station-Id or Called-Station-Id attributes, or the value of
 > the User-Name attribute. Given that, the use of Service-Type = "Call
 > Check" would not seem to apply.
 >
 > 4. Is it possible that the BNG was involved in a previous
 > transaction with the AAA server to authenticate a user? If this is
 > the case then the BNG may have received a state attribute in the
 > access-accept message. Returning this state attribute to the AAA
 > server allows the AAA server to link the 6rd request with the
 > original authentication transaction. If this is a possible scenario
 > the document should specify this since state attributes are not
 > typically used with the call-check service. Also, if it is the case
 > that there could have been a related previous authentication session
 > it seems that it should be possible to include this attribute in an
 > access-request as part of the authentication exchange.
 >
 > When DHCP information is retrieved along with user authentication why
 > is either Authorize-Only or Call Check needed?

AFACT, no meaningful authentication of anything or anybody is produced 
by your draft as it is.

>
 > Maybe I misunderstood the question from SEC AD?

I believe that he was telling you to include  the MAC address of the 
client in the Calling-Station-ID & User-Name attributes  in the request, 
along with an instance of the Message-Authenticator attribute.  Read 
Section 5.6 of RFC 2865.

 >>>>> When the BNG receives the DHCPDISCOVER, it initiates a
 >>>>> Radius Access-Request message, in which the User-Name
 >>>>> attribute is filled by 6rd CE MAC address, to the Radius
 >>>>> server, requesting authentication as defined in [RFC2865] and
 >>>>> IPv6-6rd-Configuration attribute, in the desired attribute
 >>>>> list.
 >>>>>
 >>>>> Best regards,
 >>>>>
 >>>>> Sheng
 >>>>>
 >>>>>> authentication. The RADIUS Attributes Suboption was
 >>>>>> apparently designed to carry RADIUS attributes (populated
 >>>>>> from an IEEE 802.1X exchange) from a relay agent to a DHCP
 >>>>>> server. Are you assuming that 802.1X will be used for user
 >>>>>> authentication? RFC 5969 doesn't mention .1X, nor does your
 >>>>>> draft.
 >>>>>>
 >>>>>> ...
 >

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 11 Dec 2012 06:55:23 +0000

>My biggest question, though, is who or what is

Hi, Glen,

The only reason we did not define this is because it is "normal authentication", not 6rd specific. The detailed can be found in RFC 4014 "Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option". We will add this into reference.

Sheng

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 11 Dec 2012 08:29:52 +0000

Hi, Glen,

You are right, we should define more detail BNG behavior in the authentication procedure.

New:

When the BNG receives the DHCPDISCOVER, it initiates a Radius Access-Request message, in which the User-Name attribute is filled by 6rd CE MAC address, to the Radius server, requesting authentication as defined in [RFC2865] and IPv6-6rd-Configuration attribute, in the desired attribute list.

Best regards,

Sheng

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 11 Dec 2012 09:15:57 +0000

Sheng

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 11 Dec 2012 10:02:02 +0000

>> My guess is the user-password could be the same along different users. So,
>it could be pre-configured in DHCP server. So, the below is new refined text:
>>
>Access-Request message, in which the User-Name attribute is filled by the 6rd
>CE MAC address to the Radius server and the User-password attribute is filled
>by the shared 6rd password that has been preconfigured on the DHCP server,
>requesting authentication as defined in [RFC2865] and IPv6-6rd-Configuration
>attribute, defined in the next Section, in the desired attribute list.
>

Hi, Glen,

That's what we had in 07 version as quoted below. But get DISCUSS from Security AD.

07 version, "the Access-Request packet contains a Service-Type attribute with the value Call-Check (10)."

DISCUSS from Sec AD:

3.  A RADIUS message used for call-check does not contain any information that
would authenticate the request and is therefore susceptible to forgery. 
Therefore, RADIUS messages using the 6rd attribute MUST include a
message-authenticator attribute or another attribute that is capable of
authenticating the RAIDUS packet.

The "Call Check" Service-Type was designed for situations where authorization
can be determined via the Called-Station-Id or Calling-Station-Id attributes,
which originally contained telephone numbers.  In RFC 3580,
Called/Calling-Station-Id could also contain a MAC address, but the principle
was similar -- an unique (non-authenticated) identifier which could be used to
determine whether a call was authorized.

However, this draft does not say anything about use of the Calling-Station-Id
or Called-Station-Id attributes, or the value of the User-Name attribute. 
Given that, the use of Service-Type = "Call Check" would not seem to apply.

4.  Is it possible that the BNG was involved in a previous transaction with the
AAA server to authenticate a user? If this is the case then the BNG may have
received a state attribute in the access-accept message. Returning this state
attribute to the AAA server allows the AAA server to link the 6rd request with
the original authentication transaction. If this is a possible scenario the
document should specify this since state attributes are not typically used with
the call-check service. Also, if it is the case that there could have been a
related previous authentication session it seems that it should be possible to
include this attribute in an access-request as part of the authentication
exchange.

When DHCP information is retrieved along with user authentication why is either
Authorize-Only or Call Check needed?

Best regards,

Sheng

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 12 Dec 2012 02:00:20 +0000

Hi, Glen,

My understanding now is either "call-check" in 07 version or packet flow in 08 version can work as long as we clearly define that 6rd CE MAC address should be filled in the Access-Request. Am I right?

Best regards,

Sheng

>Sent: Tuesday, December 11, 2012 5:50 PM
>To: Sheng Jiang

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 12 Dec 2012 04:53:18 +0000

I don't see any text about message-authenticator.    The requests are unauthenticated if this attribute is not present.  I suppose you could require IPSEC instead, but you probably don't want to do that.

Joe
On Dec 9, 2012, at 11:56 PM, Benoit Claise <[email-masked]<mailto:[email-masked]>> wrote:

AAA doctors,

Regards, Benoit

-------- Original Message --------
Subject:        New Version Notification - draft-ietf-softwire-6rd-radius-attrib-08.txt
Date:   Sun, 09 Dec 2012 23:15:03 -0800
From:   [email-masked]<mailto:[email-masked]>
To:     [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

IETF Secretariat.

_______________________________________________
AAA-DOCTORS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/aaa-doctors

---

From: Glen Zorn <[email-masked]>
Date: Wed, 12 Dec 2012 12:26:40 +0700

> My understanding now is either "call-check" in 07 version or packet flow in 08 version can work as long as we clearly define that 6rd CE MAC address should be filled in the Access-Request. Am I rig…

At this point I don't know if these guys are stupid or just lazy, but 
I'm getting awfully tired of dealing with it...somebody else want to 
give it a try?

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 12 Dec 2012 05:48:57 +0000

Hi, Joe,

While we can of course add some text to include message-authenticator. I still don’t understand why the message MUST be authenticated. As we analyzed in security consideration, “both BNG and AAA server are within a provider network, which can be considered as a close and less security threat environment”. Could you help me to understand by giving some detailed reason?

Sheng

From: Joseph Salowey (jsalowey) [mailto:[email-masked]]
Sent: Wednesday, December 12, 2012 12:53 PM
To: Benoit Claise (bclaise)
Cc: [email-masked]; <[email-masked]>; Ralph Droms (rdroms)
Subject: Re: [AAA-DOCTORS] New Version Notification - draft-ietf-softwire-6rd-radius-attrib-08.txt

Joe

AAA doctors,

Regards, Benoit

-------- Original Message --------
Subject:

New Version Notification - draft-ietf-softwire-6rd-radius-attrib-08.txt

Date:

Sun, 09 Dec 2012 23:15:03 -0800

From:

[email-masked]<mailto:[email-masked]>

To:

[email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

IETF Secretariat.

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 12 Dec 2012 05:59:23 +0000

Hi, Joe,

Do you actually mean the hint what/who is being authenticated by Message-Authenticator? Or the Message-Authenticator (type 80) defined in 2869.

If it is the former, according to yesterday’s discussion on AAA-doctor list, we will add 6rd CE MAC address in next update.

If it is the latter, we need some more detailed reason why it is necessary to define it.

Sheng

Joe

AAA doctors,

Regards, Benoit

-------- Original Message --------
Subject:

Date:

From:

To:

IETF Secretariat.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 12 Dec 2012 06:01:25 +0000

On Dec 11, 2012, at 9:48 PM, Sheng Jiang <[email-masked]<mailto:[email-masked]>>
 wrote:

Hi, Joe,

[Joe]  Today all networks are pretty much hostile. Distances on a network are not what they seem, an attacker is usually closer to you on the network than you think.

Sheng

From: Joseph Salowey (jsalowey) [mailto:[email-masked]<http://cisco.com>]
Sent: Wednesday, December 12, 2012 12:53 PM
To: Benoit Claise (bclaise)
Cc: [email-masked]<mailto:[email-masked]>; <[email-masked]<mailto:[email-masked]>>; Ralph Droms (rdroms)
Subject: Re: [AAA-DOCTORS] New Version Notification - draft-ietf-softwire-6rd-radius-attrib-08.txt

Joe

AAA doctors,

Regards, Benoit

-------- Original Message --------
Subject:

Date:

From:

To:

IETF Secretariat.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 12 Dec 2012 06:03:37 +0000

On Dec 11, 2012, at 9:59 PM, Sheng Jiang <[email-masked]<mailto:[email-masked]>>
 wrote:

Hi, Joe,

[Joe] Message-authenticator (type 80) to authenticate the AAA client to the AAA server.

Sheng

Joe

AAA doctors,

Regards, Benoit

-------- Original Message --------
Subject:

Date:

From:

To:

IETF Secretariat.

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 12 Dec 2012 06:14:42 +0000

Hi, Joe,

The blow text will be added in next update. It is enough to address your question?
New text: “Message-authenticator (type 80) [RFC2865] MUST be used to protect both Access-Request and Access-Accept messages.”

Sheng

From: Joseph Salowey (jsalowey) [mailto:[email-masked]]
Sent: Wednesday, December 12, 2012 2:04 PM
To: Sheng Jiang
Cc: Benoit Claise (bclaise); [email-masked]; <[email-masked]>; Ralph Droms (rdroms)
Subject: Re: [AAA-DOCTORS] New Version Notification - draft-ietf-softwire-6rd-radius-attrib-08.txt

Hi, Joe,

Sheng

Joe

AAA doctors,

Regards, Benoit

-------- Original Message --------
Subject:

Date:

From:

To:

IETF Secretariat.