Subject: [Isms] Tmsm#6: double-authentication

From: "David Harrington" <[email-masked]>
Date: Fri, 16 Feb 2007 18:36:24 -0500

Hi,

This was posted to the ietf list today, and might have an impact on
the double-authentication issue.
The terminology of course differs from isms/snmp terminology, and I
haven't gone through this thoroughly yet.
(Wes or Jeff or Joe might be able to do analysis of relevance faster
than I can.)

dbh

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]] 
Sent: Friday, February 16, 2007 4:35 PM
To: [email-masked]
Subject: New text in draft-housley-aaa-key-mgmt-08.txt

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 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sat, 17 Feb 2007 16:25:04 -0500

> (Wes or Jeff or Joe might be able to do analysis of relevance faster

I haven't looked in detail, but it doesn't look like this is relevant.  The 
issue with the AAA key management draft is that there are three parties 
involved, and they may not all know each other by the same names (for 
example, the authentication exchanges may not all be using the same 
mechanism).  In ISMS we don't have that problem - any given exchange 
involves only two parties, and only one authentication exchange that 
matters in determining the identity of each peer.

In particular, in the double-authentication case, you're doing the second 
authentication because the first one was something you got "for free" but 
is not useful.  Since the information from that authentication is thrown 
away in favor of the second one, it doesn't matter what it was, or whether 
its name was meaningful or consistent with the second authentication.  In 
fact, if it _were_, and you could tell that, then the second authentication 
wouldn't have been needed in the first place.

-- Jeff