Subject: [eap] Proposed Resolution of Issue 72

From: [email-masked] (Jari Arkko)
Date: Wed, 05 Feb 2003 17:22:15 +0200

Bernard Aboba wrote:
> I've put my proposed responses inline with a BA: preceeding them.
> 
> Issue 72: RFC 2869bis review
> Submitter name: Jari Arkko
> Submitter email address: [email-masked]
> Date first submitted: January 26, 2003
> Document: draft-aboba-radius-rfc2869bis-07.txt
> Comment type: T
> Priority: S
> Section: various
> Rationale/Explanation of issue:
> 
> Comments marked with "JARI:"
> 
> JARI: I think we need a section on what has been updated since RFC 2869.
> BA: Yes. I will add this.
> 
> 1.  Introduction
> 
> [RFC2865] describes the RADIUS Protocol as it is implemented and deployed
> today, and [RFC2866] describes how Accounting can be performed with
> RADIUS.
> 
> JARI: Remove "as it is implemented and deployed today". I don't think
> RFC2865 talks about implementation or deployment.
> BA: Done.
> 
> In order to provide for support of EAP within RADIUS, two new
> 
> JARI: s/provide for support of/support/
> BA: Done.
> 
> Once EAP has been negotiated, the NAS SHOULD send an initial EAP-Request
> message to the authenticating peer.  This will typically be an
> EAP-Request/Identity, although an EAP-Request for an alternate EAP method
> is possible. For example, a NAS might be
> 
> JARI: s/alternate/actual authentication/?
> BA: Done.
> 
> This could be usefulin cases where the identity is determined by another
> means (such as the Called-Station-Id or Calling-Station-Id), a single
> authentication method is required (so that the identity is not needed to
> determine the method), or where identity hiding is desired, so that the
> identity is not requested until after a protected channel has been set up.
> 
> The peer responds with an EAP-Response, which the NAS encapsulates within
> EAP-Message attribute(s) within a RADIUS Access-Request packet, sent to
> the RADIUS server. For example, if an EAP-Request/Identity message is sent
> by the NAS as the first packet, the peer responds with an
> EAP-Response/Identity, and the NAS encapsulates the EAP-Response/Identity
> message within EAP-Message attribute(s), enclosed within an Access-Request
> sent to the RADIUS server.
> 
> JARI: In the above, we need a discussion of the possibility that the
> NAS decides at this point to run a local method. Add: "Alternatively, the
> NAS may determine from the response that it should proceed with local
> authentication. Once the NAS has begun the use of RADIUS authentication
> for a particular session, it no longer can perform local authentication."
> 
> If the RADIUS server supports EAP, it MUST respond with an
> Access-Challenge packet containing EAP-Message attribute(s). If the RADIUS
> server does not support EAP, it MUST respond with an Access-Reject.
> BA: Done.
> 
> JARI: Support vs. wants to do vs. wants to do for this particular user?
> BA: Done.
> 
> EAP-Message attribute(s) encapsulate a single EAP packet which the NAS
> decapsulates and passes on to the authenticating peer.  The conversation
> continues until either a RADIUS Access-Reject or Access-Accept packet is
> received from the RADIUS server.  Reception of an RADIUS Access-Reject
> packet MUST result in the NAS denying access to the authenticating peer. A
> RADIUS Access-Accept packet successfully ends the authentication phase.
> 
> JARI: This could my lack of knowledge in RADIUS, but what about the
> simultaneous bidir authentications? What does the Access-Accept signify in
> that case? Both end at that time, or can we open up a new RADIUS dialog
> for the other auth? And what happens if the NAS/RADIUS doesn't even want
> to authenticate the peer, but the peer insists on authenticating the
> NAS/RADIUS? Seems like the initiate-with-Id-Request -approach seems wrong
> in such a case.
> BA: Each authentication is handled as a separate RADIUS session, or
> else things get very confusing. However, where the client is attempting to
> authenticate the NAS, Accept doesn't mean "grant access" or that would
> open a security loophole. Perhaps that is an argument to remove this text
> altogether. It can cause trouble and I don't expect it to be implemented
> widely.

Everything above looks OK.

Just out of curiosity: If a rogue client dials up a NAS supporting
original RFC 2869 and does the following, what will happen:
   - Open the lower layer connection
   - The NAS starts EAP towards the client but it doesn't answer
   - Instead, it starts EAP towards the NAS (e.g. sends identity request)
   - The client doesn't really execute any method but sends a Success
     message to the NAS
My question is, will the NAS/AAA respond with Access-Accept to the Success
message sent by the client, even if the EAP authentication to the other
direction is still ongoing. If so, will the NAS let the user in?

> Using RADIUS, the NAS can act as a pass-through for an EAP conversation
> between the peer and backend authentication Server, without needing to
> implement the EAP method used between them.  Even where the NAS initiates
> the conversation by sending an EAP-Request, it is not required that the
> NAS fully implement the EAP method sent in the first packet. Depending on
> the method, it may be sufficient for the NAS to be configured with the
> initial packet to be sent to the peer, and for the NAS to act as a
> pass-through for subsequent messages.
> 
> JARI: The above is somewhat unclear. Do you or do you not require just the
> identity request to be sent by the NAS? Or do you require also a canned
> first message to be sent if no id request is needed? Besides, not all
> methods can have a canned first message, e.g. challenge-response...
> 
> BA: I've rewritten this section to improve clarity. See what you think:
> http://www.drizzle.com/~aboba/EAP/draft-aboba-radius-rfc2869bis-08.txt
> 
> In order to permit non-EAP aware RADIUS proxies to forward the
> Access-Request packet, if the NAS initially sends an EAP-Request/Identity
> message to the peer, the NAS MUST copy the contents of the Type-Data field
> of the EAP-Response/Identity received from the peer into the User-Name
> attribute and MUST include the Type-Data field of the EAP-
> Response/Identity in the User-Name attribute in every subsequent
> Access-Request.
> 
> JARI: Only because of non-EAP aware proxies? What does the EAP-aware proxy
> use for routing the messages to the right direction, User-Name or contents
> of the EAP messages? I think the former... so its for the operation of all
> proxies, right?
> 
> BA: User-Name, because the proxies also act as pass-throughs. I've added
> some text to clarify this.
> 
> JARI: I'm hoping the above "MUST copy" doesn't apply for an EAP Id
> req/resp pair appearing within a tunneled method or in a sequence... (the
> NAS might be able to see this message pair if it executed the first part
> itself and *then* let RADIUS handle the rest. Or did we prohibit such
> cases already?)
> 
> BA: The NAS cannot see the inner method in a tunnel because it acts as a
> pass-through and does not decrypt EAP messages passing through it. The use
> of Reply-Message is now deprecated, in favor of EAP-Request/Notification.
> 
> The NAS-Port or NAS-Port-Id attributes SHOULD be included by the NAS in
> the Access-Request packet, and either NAS-Identifier or NAS-IP-Address
> attributes MUST be included.  In order to permit forwarding of the
> Access-Reply by EAP-unaware proxies, if a User-Name attribute was included
> in an Access-Request, the RADIUS server MUST include the User-Name
> attribute in subsequent Access-Challenge, Access-Accept or Access-Reject
> packets. Without the User-Name attribute, accounting and billing becomes
> difficult to manage.  If the identity is determined by another means, such
> as the Calling-Station-Id, the NAS MUST include these identifying
> attributes in every Access-Request, and the RADIUS server MUST copy these
> identifying attributes into subsequent Access-Challenge, Access-Accept or
> Access-Reject packets.
> 
> JARI: Uh.... so identity hiding breaks roaming completely? There seems to
> be two issues that we need to deal with:
> 
> 1) How to route the request to the right place. Here it is hard for me to
> see any solutions. Or perhaps hiding just the user name but not the domain
> as was done in EAP SIM & AKA. But we don't have the general machinery in
> EAP for that.
> 
> 2) How to associate the accounting records with the right user? Would the
> Class attribute be suitable in this situation? The records would carry the
> information, but only the home network can correlate them with the actual
> user.
> 
> BA: Class attribute can be added, yes. I've added to the table of
> attributes to make this clear.

OK, but you may need to list this in section 2.1 where it says "identity
is determined by other means". Shouldn't we also explain how Class might
help here?

> Having the NAS send the initial EAP-Request packet has a number of
> advantages:
> 
> JARI: [3] Allowing for local authentication for some users.
> BA: Done.
> 
> In this case, the NAS MAY also send an Access-Request packet to the RADIUS
> server containing an EAP-Message attribute signifying EAP-Start. This
> allows the RADIUS server to take over the task of negotiating a more
> suitable method.
> 
> JARI: Question - does the NAS include the contents of the Nak and the
> request that led to it when sending this EAP-Start?
> BA: I've clarified the text to indicate that it is possible to send
> the Nak embedded in the initial Access-Request, to give the RADIUS server
> a hint about what the peer wants to do. However, when that is done, an
> EAP-Start is *not* included as well.
> 
> 2.2.  Role reversal
> 
> Since EAP is a peer-to-peer protocol, an independent and simultaneous
> authentication may take place in the reverse direction. Both peers may act
> as authenticators and authenticatees at the same time.
> 
> Support for role reversal is optional on the RADIUS server, and requires
> 
> JARI: Why optional? How about mandatory to implement, optional to
> configure the server to actually do it? If we required mandatory support
> for this, would this increase the likelihood protection against rogue
> NASes? Or maybe we should require mutual auth support in EAP.
> BA: I'm now leaning toward removing support for role reversal.

Ok.

> The RADIUS server then replies with an Access-Accept (in response to an
> EAP-Success) or an Access-Reject (in response to an EAP-Failure),
> containing no EAP-Message attribute.
> 
> JARI: May need to explain how the two RADIUS dialogs are independent, i.e.
> Access-Accept as a response to the above kind of Access-Request does *not*
> mean the other auth is complete and the user should be let in. Also, I'm
> uncertain what happens in the user is authenticated to the NAS/RADIUS
> first and an Access-Accept is returned, and *then* the user initiates EAP
> in another direction. Can this happen with PPP? 802.1X?
> BA: I don't think I can explain it -- so it probably should be removed.
> 
> This can be accomplished by inclusion of Session-Timeout and
> Password-Retry attributes within the Access- Challenge packet.
> 
> JARI: I don't understand Password-Retry in this context. Wouldn't it be
> the RADIUS server that only is aware of an authentication failure, and
> would also need to send the new Requests to make possible the use of a new
> password?
> BA: On reflection, neither do I. I've removed all mention of this
> attribute in the text, and indicated in the attribute table that it
> isn't used in EAP conversations.
> 
> If Session-Timeout is present in an Access-Challenge packet that also
> contains an EAP-Message, the value of the Session-Timeout provides the NAS
> with the maximum number of seconds the NAS should wait for an EAP-Response
> before retransmitting the EAP-Request.
> 
> JARI: Please clarify whether this can be received multiple times, and what
> the semantics are. E.g. first you start PEAP and timeout is 5 s, then
> inside you'll be running token caard and timeout is 60 s, apparently the
> NAS takes the latest received timeout value, and starts counting from the
> time that it received this value from the NAS?
> BA: Yes.
> 
> As described in [RFC2284], the EAP Success and Failure packets are not
> 
> JARI: Update refs to 2284bis?
> BA: Since RFC 2869bis needs to be published right away since it is a
> dependency of IEEE 802.1aa, and 802.1aa does not have a dependency on
> RFC2284bis so far, adding one is probably not a good idea.
> 
> Since the responsibility for avoiding these conflicts lies with the RADIUS
> server, the NAS MUST NOT "manufacture" EAP packets in order to correct
> contradictory messages that it receives. This behavior, originally
> mandated within [IEEE8021X], has since been deprecated.
> 
> JARI: So, what does it do then? MUST disconnect?
> BA: The client can't tell if the NAS is manufacturing or not, so I can't
> see any way to act differently.
> 
> 2.6.2.  Priority
> 
> In addition to containing EAP-Message attributes, RADIUS messages may also
> contain other attributes. In order to ensure the correct processing of
> RADIUS messages, the NAS SHOULD process EAP-Message attributes last.
> 
> JARI: We need more detail here. Say, Session-Timeout is one of these other
> attributes. What does 'process' mean? Look at the EAP message contained in
> the packet? Send that message to the peer and expect it to answer -- if
> so, the timeout setting would be handled too late.
> BA: It means send the message to the peer.
> 
> 
> It is possible that the chosen Identifier value will conflict with a value
> chosen by the RADIUS server for another packet within the EAP
> conversation. This would violate the requirement that  the Identifier be
> unique within an  EAP conversation.
> 
> JARI: And after this, its still a MAY? Backwards compatibility prevents us
> prohibiting it?
> BA: I've made it a SHOULD NOT.
> 
> When used within an EAP conversation, a Reply-Message attribute received
> by the NAS MAY be translated to an EAP-Request/Notification sent to the
> peer. As a result, a Reply-Message attribute MUST NOT be included in a
> RADIUS message containing an EAP-Message attribute. An
> EAP-Message/EAP-Request/Notification or Reply-Message attribute SHOULD NOT
> be included within an Access-Accept or Access-Reject packet representing
> the conclusion of an EAP conversation.
> 
> JARI: But this is in conflict in 2.6.3! Delete 2.6.3 and use this instead?
> BA: I've integrated this with 2.6.3.
> 
> Value
> 
> The Value field is four octets, containing an integer specifying the
> number of password retry attempts to permit the user.
> 
> JARI: I must be missing something obvious again. What does the NAS do with
> this information? If it is running EAP and carrying it over to the RADIUS
> server, it doesn't appear to be able to tell whether the response messages
> from the peer used the right password or not. Nor can it resend Requests,
> there'd be Identifier conflicts, no?
> BA: Good catch. I've removed mention of Password-Retry, since on
> reflection it doesn't make sense to me either.
> 
> RADIUS over IPsec, defined in [RFC3162] will eventually make this
> attribute obsolete, so it should be considered an interim measure.
> 
> JARI: When is the time to start requiring this? Or should new protocols
> just start using DIameter instead?
> BA: I've made it a SHOULD.
> 
> 
> Vulnerabilities include:
> 
>        Separation of EAP server and authenticator
>        Dictionary attacks
>        Known plaintext attacks
>        Replay protection
>        Connection hijacking
>        Man in the middle attacks
>        Multiple databases
>        Negotiation attacks
> 
> JARI: No DoS? Reading on...
> BA: Do you have some text to suggest?

No, one of my later comments was that I couldn't figure out any
specific DoS attack on this.

> For the authenticating peer, authentication policy should be set on a
> per-connection basis. Per-connection policy allows an authenticating peer
> to negotiate a strong EAP method when connecting to one service, while
> negotiating a weaker EAP method for another service.
> 
> JARI: Per-service or per-connection? If its per-connection, what if the
> attacker causes a disconnect, then offers a weaker method? Ah, the
> explanation below clarifies this. Wouldn't the right name for this be
> "per-service"?
> BA: Yes. Now using that term.
> 
> An authenticating peer expecting EAP to be negotiated for a session MUST
> NOT negotiate a weaker method, such CHAP or PAP.
> 
> JARI: s/such/such as/
> BA: Done.
> 
> wireless networks, the service advertisement itself may be spoof-able, so
> that an attacker could fool the peer into negotiating an authentication
> method suitable for a less secure network.
> 
> JARI: Ouch! So, per-service isn't very helpful either unless you support
> the same security level for all services.
> BA: yes.
> 
> EAP-capable authenticating peer MUST refuse to renegotiate the
> authentication protocol if EAP had initially been negotiated.  Note that
> problems with a non-EAP capable RADIUS proxy could prove difficult to
> diagnose, since a user connecting from one location (with an EAP-capable
> proxy) might be able to successfully authenticate via EAP, while the same
> user connecting at another location (and encountering an EAP-incapable
> proxy) might be consistently disconnected.
> 
> JARI: Ok, so to get back to the DoS issue... let's see: No, I can't think
> of any additional dos problems beyond those already present in EAP.
> BA: OK.
> 
> 5.  Normative references
> 
> JARI: I'm not sure why the above ones are normative. At least the first
> one should be informative?
> BA: Probably.

I've taken a look at your -08 and the above responses. Everything
looks good, except maybe some additional clarification for Class.

Jari

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 5 Feb 2003 06:18:49 -0800 (PST)

>    - Open the lower layer connection

My guess is that most implementations will not send a RADIUS Request with
an EAP-Start.

>    - The NAS starts EAP towards the client but it doesn't answer

The EAP conversation will time out, and no RADIUS Access-Request will be
sent.

>    - Instead, it starts EAP towards the NAS (e.g. sends identity request)

Hmm. We would have to ask implementors what they will do. Hopefully they
can handle it :)

>    - The client doesn't really execute any method but sends a Success

Hopefully this won't result in access to the NAS :)

> direction is still ongoing. If so, will the NAS let the user in?

I certainly hope not. But we should ask implementors what they do.

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 5 Feb 2003 06:37:27 -0800 (PST)

> is determined by other means". Shouldn't we also explain how Class might

OK. Can you propose some text?

---

From: [email-masked] (Jari Arkko)
Date: Wed, 05 Feb 2003 19:54:28 +0200

EAP State Machine Design Team conference call on 2/5/03

Date:       Wednesday, February 5, 2003
Time:       8-9 AM PST
Present:    I got in last, but at least Bernard, Nick, Yoshihiro, John, Bob, Paul, and Jari

o Peer-to-peer nature of the EAP protocol

   Bob: The IEEE link security group wants a peer-to-peer protocol, and
   isn't quite sure EAP is. Bob said it is. Bernard: It is, but there
   are some issues involved in running EAP both ways that Jari brought
   up in the context of RFC 2869bis. What happens when access-accept is
   given for a client-initiated EAP run, for instance?

   John: I think we have a terminology problem. The authenticator in a
   mutual authentication method is more like an initiator a la IKE than
   the authenticator. Bob: You could use these terms, but each system
   would still have both roles. Bernard: In most cases one doesn't want
   them to be both roles, except maybe in 802.11 ad hoc mode.

   Jari: There isn't complete symmetry here, identity is given only to
   peer not to the authenticator. Bernard: some people have been asking
   for this functionality.

   Bob: There are race conditions. In 802.1x, there can be multiple
   identity requests sent with different identifier counter values, so
   they are not detected as duplicates. The RADIUS server will get
   multiple requests, and this can be confusing.

   Bernard: Two-way authentication and 2869bis has a problem: Jari was
   asking too many questions and I removed the support for this as a
   result. John: I will take a look at the discussion to see if the
   two-way authentication would still be possible.

o Protected successes and failures

   John: not too happy with this in the current document.

   Bernard: Question to Paul: What is the order of processing in 2869
   of keys vs. attributes.  Paul: The state machine, I think, makes
   this clear.  The attributes have to be processed first before
   anything else is done. Bernard: RFC 2869bis and the state machine
   are at least in sync then.

   John: The protected success and failures may be a bit of a red
   herring. Waybe we should put something about this in the security
   considerations and delete the rest of the text. Bernard: this has
   already been done in -10, we now talk only about protected
   indications with EAP itself, no relation to lower layer protection
   etc.

   Bernard: Does who tells you matters? What if method tells me it
   failed. Should I be able to send a success? John: No.  It would be
   better to use terms like "method signals success or failure" than
   the current ones. If the authenticator can tell the peer through a
   method that it succeeded, that would be useful. Bernard: the
   question is are the success and failure messages processed
   differently based on what happened in the method?  John:
   yes. Bernard: we agree on this, but we need to specify how. For
   instance, we talked about not accepting a success before the method
   was done.

o Peer state machine document

   - A preliminary state machine for the peer state machine has been
     posted to the design team list. A slide set describing the
     interfaces between 802.1x and EAP has also been posted to the same
     list.

   - Nick: In the current peer state machine, I'm not very happy with
     the specific names for variables.  The variables need to be
     generalized to make the state machine more generally applicable
     for different environments.

   - Methods either do integrity checks or don't, and go back to the
     Idle state through different routes based on this.

   - Based on Yoshihiro's comments an ability has been added to resend
     a response if the request id is the same as the last id.

   - Nick: success and failure conditions are currently unclear. I'd
     like to enumerate all conditions when I can fail or succeed.

   - Bob: One comment I have: The machine starts with a link enabled
     signal. In the link security discussion at IEEE, there's
     discussion on needing authentication where there is no link
     signaling. John: I think this is a part of Nick's desire to have
     more generic names: Nick: Yes. Bob: when link comes up, you still
     need other mechanisms to find out who you want to authenticate
     with. Nick: Its like 802.11 Associate. Bob: Yes.

     We also have link-down-link-up events, which can cause problems if
     they go unnoticed. Bob: if the authentication is to an end system,
     you may not care about the link which doesn't matter so much.

     Nick: I agree that link is the wrong term here. Bob: there has to
     be some sort of discovery process. Nick: Yes. Maybe its something
     coming from the hardware. Also, if we get the signal that the
     other side is no longer there, we have to abort EAP.

     John: there should be two signals, a reset and a "start
     authentication" signal. Nick: Link enabled could become something
     like "channel enabled" and this would have to stay true all the
     time, otherwise we abort. A single variable like this works
     well, as long as we have the "channel" structure. For
     reauthentication we may need another variable, because you want to
     stay port open while working through reauthentication. That still
     leaves the question of which state to go in that case. Maybe you
     should remain in the success state.

   - Question: does the method signal the success/failure result? Nick:
     that's the method state variable.

   - Question: does the method control policy or the policy the method?

     Bob: We have been talking about a sequence of method. You could
     imagine a policy which is more of a decision tree of a method.

     Yoshiri: yes, and I think that is needed.  It should be possible
     to allow one method only once, for instance. I suggest adding an
     update policy call in the peer state machine outside the method
     exchange.

   - Comment: I'm unclear how to go back to dialog if i discard a
     message through mic.  Oh I see, there's a retransmission and
     through this i get to dialog. Bernard: its a problem, because the
     authenticator would just retransmit the same bad message. John:
     this is for an injected message on the path. bernard: Yes, for
     that it would work.

     It would be good to document what we can do with DoS. All:
     Agreed. Bernard: it is important to avoid rogue successes.  Other
     stuff is hard to protect against, for instance diassociate link
     message can be easily spoofed and that would disable the link.

     Bernard: the mic check on the authenticator in passthrough mode
     isn't doaable, as Yoshihiro noted. Given that the NAS would also
     be eliminating duplicates, this is a dos attack. Yoshihiro: I
     think we should just delay the duplicate elimination until the AAA
     server incidcates whether the packet was correct or not. Bernard:
     Today it would send back an access-reject. Unless duplicate
     detection is turned off or delayed we can't do more. John: We
     could provide a RADIUS message that says "I didn't like this, give
     me another one if you have". Bernard: the problem is that this
     would be a massive change. And this isn't backwards compatible.
     John: before we decide this we should design it first so that we
     can see if this would happen. Certainly for the way its presented
     now it would not work.

     Bernard: there are limitations what we can do because we have
     deployed protocol implementations to the field already.

     Jari: It would have been better if passthrough NASes didn't do
     duplicate detection and left it to AAA.  Bernard: Yes. John: Not
     sure if we couldn't still do it?

   - Nick: Do we agree that the only time you can get success is at the
     end of a method? Bernard: yes.  John: No. I think it can go to
     success if its satisfied with its policy and it gets a timeout. If
     the other end failed the link won't be up. Both ends have to
     enable it. I'm willing to go along with the above, however, if we
     have a real discussion about this and people agree.  Bernard: this
     is about the 2284 text on alternative indications. John:
     Generally, this indication is that "the link worked". Bernard: The
     problem is that you can spoof link up messages.

---

From: [email-masked] (Jari Arkko)
Date: Thu, 06 Feb 2003 11:20:17 +0200

> OK. Can you propose some text?

Well here's one suggestion. This is intended to be appended to the
2.1 paragraph that begins with "The NAS-Port or NAS-Port-Id
attributes SHOULD ...":

     None of these attributes may be present where identity hiding
     is desired. It is generally not possible to hide the full NAI
     if proxies with User-Name based routing are used. In some
     networks all the attributes can be hidden, however. If the User-Name
     attribute is not present in the Access-Request packet, the
     RADIUS server SHOULD include a Class attribute in the Access-Challenge,
     Access-Accept, and Access-Reject packets. According to the rules
     in [RFC2865] the contents of this attribute are copied unmodified
     to Accounting-Request packets. This allows the RADIUS server to
     provide information that enables it to correlate the accounting
     records with the particular user that was authenticated. If the
     Class attribute is used, its contents MUST be encrypted to
     hide the identity of the user from those not in the possession
     of a local secret known to the RADIUS authentication and
     accounting servers. Similarly, if the Access-Request packet
     did not include a User-Name attribute, the RADIUS server MUST
     NOT add a User-Name attribute to the Access-Challenge, Access-Accept,
     or Access-Reject packets even if it knows the identity of the user.

Jari

---

From: [email-masked] (Bernard Aboba)
Date: Fri, 7 Feb 2003 07:13:30 -0800 (PST)

>      is desired.

Here's what RFC 2865, Section 4.1 says:

      An Access-Request SHOULD contain a User-Name attribute.  It MUST
      contain either a NAS-IP-Address attribute or a NAS-Identifier
      attribute (or both).

So I think that this would be a violation of RFC 2865, no?

>      It is generally not possible to hide the full NAI
>      networks all the attributes can be hidden, however.

How are they hidden? Using the MD5 encryption construction in RFC 2865? By
some other means?

>      If the User-Name
>      Access-Accept, and Access-Reject packets.

The Class attribute is forbidden in Request, Reject and Challenge
packets in RFC 2865, so we will need to figure out another way to do this.

Here's what RFC 2865, Section 5.1 says:

      This Attribute indicates the name of the user to be authenticated.
      It MUST be sent in Access-Request packets if available.

      It MAY be sent in an Access-Accept packet, in which case the
      client SHOULD use the name returned in the Access-Accept packet in
      all Accounting-Request packets for this session.  If the Access-
      Accept includes Service-Type = Rlogin and the User-Name attribute,
      a NAS MAY use the returned User-Name when performing the Rlogin
      function.

Would it be possible to return the desired identifier within the User-Name
attribute in the Access-Accept? I think that would accomplish what you
want.

>      According to the rules
>      accounting servers.

The original specification for the Class attribute does not include any
mention of message hiding. So I don't think that we can introduce that in
RFC 2869bis. We could of course define a new attribute -- or since IPsec usage
is now a SHOULD, we could assume IPsec protection and not worry about it.

>      Similarly, if the Access-Request packet

In RFC 2865, User-Name is a MUST NOT in the Reject and Challenge.

---

From: [email-masked] (Jari Arkko)
Date: Fri, 07 Feb 2003 22:49:12 +0200

>       contain either a NAS-IP-Address attribute or a NAS-Identifier
...
> packets in RFC 2865, so we will need to figure out another way to do this.
...
 > is now a SHOULD, we could assume IPsec protection and not worry about it.

Ok, I'm convinced that we can't do what I originally thought.

> attribute in the Access-Accept? I think that would accomplish what you

Yes. But I was worried about attacks that might expose the AAA packet on
the wireless side, and RADIUS a la plain 2865 would then expose User-Name.
But as you say, maybe this isn't an issue if we have IPsec running.

Jari

---

From: [email-masked] (Bernard Aboba)
Date: Fri, 7 Feb 2003 12:05:07 -0800 (PST)

> But as you say, maybe this isn't an issue if we have IPsec running.

This is just one of many reasons why I think IPsec is very important.

Would like some text describing how the User-Name could be sent in the
access accept, or why IPsec is very important when Identity hiding is in
use?