RE: [security-services] Authentication Methods

security-services message

Subject: RE: [security-services] Authentication Methods - Proposed changes tocore-29

From: "Hallam-Baker, Phillip" <pbaker@verisign.com>

To: 'Hal Lockhart' <hal.lockhart@entegrity.com>,"Hallam-Baker, Phillip" <pbaker@verisign.com>,"'Philpott, Robert'" <rphilpott@rsasecurity.com>,security-services@lists.oasis-open.org

Date: Thu, 04 Apr 2002 07:20:18 -0800

Title: Authentication Methods - Proposed changes to core-29

There are no places where Base64 encoding should be specified. (See below) Therefore this sentence should not go here. If there are other Base64 encoded items earlier in the document, perhaps a similiar reference to [RFC 2045] should be included at the appropriate place.

Ah yes, thats right, ok that has gone

However see below, I have added some additional references for PGP, SPKI etc to make up.

1.1.1. Password (Pass-Through):

First, I assume this is supposed to be 7.1.1 etc.

Yes that is what happens when you cut and paste from Word to Outlook

I explictily specified leaving out the "(Pass-Through)" In what sense is this a pass-through? The System Entity sent a password to the Authentication Authority. The AA confirmed that the password was correct. The AA later issed an assertion with an Authentication Statement in it. The AA did not pass-through the password to anybody. Please drop "(Pass-Through):" from the title as I specified previously.

That was just an oversight

URI: urn:oasis:names:tc:SAML:1.0:am:password

The authentication was performed by means of a password.

1.1.2. Kerberos
URI: urn:ietf:rfc:1510
<SubjectConfirmationData>: A Kerberos Ticket
No, no, no. There is no such thing as Subject Confirmation Data. What we are defining here is Authentication Method. It goes in the AuthenticationMethod attribute of the Authentication Statement. Look at the schema. (lines 667 & 1814 in core-29) There is no <SubjectConfirmationData>. There is no Authentication Data. There is no data of any kind, just the Method identifier. That is the point of this entire revision.

Also an overisght

Theauthentication was performed by means of the Kerberos protocol [RFC 1510], an instantiation of the Needham-

Should be a space between "The" and "authentication". (I'm surprised your picky grammer checker didn't catch that one. ;-)

Track changes does some genuinely bizare things

Schroeder symmetric key authentication mechanism [Needham78] .

1.1.3. SSL/TLS Certificate Based Client Authentication:

URI: urn:ietf:rfc:2246

The authentication was performed using either the SSL or TLS protocol with certificate based client authentication. TLS is described in [RFC 2246].

1.1.4. X.509 Public Key

URI: urn:oasis:names:tc:SAML:1.0:am:X509-PKI

The authentication was performed by some (unspecified) mechanism on a key authenticated by means of an X.509 PKI. It may have been one of the mechanisms for which a more specific identifier has been defined below.

1.1.5. PGP Public Key

URI: urn:oasis:names:tc:SAML:1.0:am:PGP

The authentication was performed by some (unspecified) mechanism on a key authenticated by means of a PGP web of trust. It may have been one of the mechanisms for which a more specific identifier has been defined below.

1.1.6. SPKI Public Key

URI: urn:oasis:names:tc:SAML:1.0:am:SPKI

The authentication was performed by some (unspecified) mechanism on a key authenticated by means of a SPKI PKI. It may have been one of the mechanisms for which a more specific identifier has been defined below.

I have no objection to adding this identifier. However I was under the impression that XKMS was doing X509 or PGP or SPKI. Does it use a distinct trust model?

It can do, one of the possible XKMS configuration is in chained mode in which there is no backing PKI, just a database of keys.

The other issue is that the whole point of XKMS is that the client does not need to know what is underneath so the client does not kow that it is a PGP key or an X.509 key, all it knows is it is trusted for purpose X with person Y.

1.1.7. XKMS Public Key

URI: urn:oasis:names:tc:SAML:1.0:am:XKMS

The authentication was performed by some (unspecified) mechanism on a key authenticated by means of a XKMS trust service. It may have been one of the mechanisms for which a more specific identifier has been defined below.

1.1.8. XML Digital Signature

URI: urn:ietf:rfc:3075

The authentication was performed by means of an XML digital signature [RFC 3075].

Regards,

Subject Confirmation Methods are defined in the SAML Profile or Profiles in which they are used [SAMLBind]. Additional methods may be added by defining new profiles or by private agreement.

The following identifiers refer to SAML specified Authentication methods.

7 .1.1. Password :

URI: urn:oasis:names:tc:SAML:1.0:am:password

The authentication was performed by means of a password.

7 .1.2. Kerberos

URI: urn:ietf:rfc:1510

The authentication was performed by means of the Kerberos protocol [RFC 1510], an instantiation of the Needham-Schroeder symmetric key authentication mechanism [Needham78] .

security-services message

1.1.1. Password (Pass-Through):

1.1.2. Kerberos

1.1.3. SSL/TLS Certificate Based Client Authentication:

1.1.4. X.509 Public Key

1.1.5. PGP Public Key

1.1.6. SPKI Public Key

1.1.7. XKMS Public Key

1.1.8. XML Digital Signature

7 .1.1. Password :

7 .1.2. Kerberos

7 .1.3. SSL/TLS Certificate Based Client Authentication:

7 .1.4. X.509 Public Key

7 .1.5. PGP Public Key

7 .1.6. SPKI Public Key

7 .1.7. XKMS Public Key

7 .1.8. XML Digital Signature