New text in draft-housley-aaa-key-mgmt-08.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




I'd like to draw your attention to changes made to resolve my discuss
comments on Russ's key management draft.  The authenticate all parties
section has been changed to the following new text.  Please let us
know if you have concerns about the text; the draft is scheduled for
approval in somewhat over a week.

	 Each party in the AAA key management protocol MUST be
	 authenticated to the other parties with whom they communicate.
	 Authentication mechanisms MUST maintain the confidentiality of
	 any secret values used in the authentication process.

	 When a secure association protocol is used to establish session
	 keys, the parties involved in the secure association protocol
	 MUST identify themselves using identities that are meaningful
	 in the lower layer protocol environment that will employ the
	 session keys.  In this situation, the authenticator and peer
	 may be known by different identifiers in the AAA protocol
	 environment and the lower layer protocol environment, making
	 authorization decisions difficult without a clear key scope.
	 If the lower layer identifier of the peer will be used to make
	 authorization decisions, then the pair of identifiers
	 associated with the peer MUST be authorized by the
	 authenticator and/or the AAA server.

	 AAA protocols such as RADIUS [RFC2865] and Diameter [RFC3588]
	 provide a mechanism for the identification of AAA clients;
	 since the EAP authenticator and AAA client are always co-
	 resident, this mechanism is applicable to the identification of
	 EAP authenticators.

	 When multiple base stations and a "controller" (such as a WLAN
	 switch) comprise a single EAP authenticator, the "base station
	 identity" is not relevant; the EAP method conversation takes
	 place between the EAP peer and the EAP server.  Also, many base
	 stations can share the same authenticator identity.  The
	 authenticator identity is important in the AAA protocol
	 exchange and the secure association protocol conversation.

	 Authentication mechanisms MUST NOT employ plaintext passwords.
	 Passwords may be used provided that they are not sent to
	 another party without confidentiality protection.



_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]