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

[Hal Lockhart <hal.lockhart@entegrity.com>]

Title: Authentication Methods - Proposed changes to core-29

I take exception to a few things that differ from what I explicitly changed from core-29.

-----Original Message-----
From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]
Sent: Wednesday, April 03, 2002 4:20 PM
To: Hallam-Baker, Phillip; 'Hal Lockhart'; 'Philpott, Robert'; security-services@lists.oasis-open.org
Subject: RE: [security-services] Authentication Methods - Proposed changes to core-29

Proposed complete text:

 

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. Where Base64 encoding is specified the data is encoded as specified by [RFC 2045]. 

 

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.

1.1.1. Password (Pass-Through): 

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

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.

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.

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. ;-)

 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?

 

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,

 

Hal