OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: AuthenticationMethod / NameIdentifier and Kerberos authentication

> So far we have been assuming that the AuthenticationMethod should be :
> URI: urn:ietf:rfc:1510

I would also like to suggest that we clarify this this doesn't mean "give
password to server and server does 1510" but that it requires a real client.
> It appears to me that we could add the pre-auth data type 
> onto this to become :
> URI: urn:ietf:rfc:1510:padata-type:<n>
> <n> is the preauthentication datatype as specified in the 
> IETF draft or RFC specific to the authentication type

We could do this, I guess I'm wondering if it scales reasonable, or if this
topic is better handled with AuthnContext. I'd like to work out the best
approach to this with JohnK. If the AuthnMethod URIs are supposed to map to
AuthnContext classes, I want to be sure this will be viable.

> However, if we have multiple NameIdentifiers, maybe we want 
> to represent the Format for each principal that was 
> authenticated to give uniqueness - see below :
> URI: 
> urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos:padata-type:<n>
> <n> is the preauthentication datatype as specified in the 
> IETF draft or RFC specific to the authentication type
> What do you think ?

This one I disagree with. NameID formats have nothing directly to do with
authentication type, it's just a way of representing/describing the
principal. If the ticket always has principal@realm, that's what the format
needs to capture, not the preauth type.

> Once we are in agreement as to what is needed I can write 
> some normative text for inclusion on the specs.

I did add the 1510 NameID format to the core spec and it's in Eve's hands.
> We also need to consider adding text to the authnrequest 
> description so that a Kerberos initial ticket (tgt) lifetime 
> can be carried over into the lifetime of the assertion.

First we have to decide what lifetime is. ;-)

I think this would argue for my suggestion to move the short-lived interval
to a bearer condition/confirmation and then you could consider this. But I
don't know exactly where it would go except to maybe clarify what validity
would mean in the protocol.

-- Scott

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]