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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-core message

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


Subject: RE: conference call - March 29


Title:
Phill,
 
I am having trouble understanding your reply to my questions.
 
First you did not seem to reply to my request for clarification:
 
>In the 0.3 version of the document, I am unclear about the box at the top of page 11 that starts "Alternate means of
>identifying the assertion" Are these design alternatives or are you proposing to support a number of different ways of
>identifying the same assertion?
 
Second, I am unclear as to what aspect of my comment you agree with.
 
Let me propose that we distinguish between the initial Authentication performed by a system entity using password, private key, etc. (Authentication) and the verification of the binding of some assertion or ticket to a session, principal or request (VOB). [If anybody can think of a more natural term which does not already have other meanings, please suggest it.]
 
I assume that in your message, where you say "authentication" you mean VOB.
 
Clearly the MAC scheme proposed in the document involves a pre-shared secret. However the hashing scheme I proposed does not and in fact is as secure as any cookie-type* scheme can be.
 
I am not sure exactly what you mean by the second paragraph, but I don't think I am on shaky ground if I say that any scheme that requires all participants to have keys and certificates is a complete non-starter.
 
Could you amplify you comments a bit so I can better understand your thinking. Alternatively if the next draft of you document will clarify these points, I will look forward to its publication.
 
Hal
 
*By cookie-type scheme I mean a VOB based on returning a previously issued value without modification. Web cookies are an example, Kerberos tickets are not.
-----Original Message-----
From: Philip Hallam-Baker [mailto:pbaker@verisign.com]
Sent: Friday, March 30, 2001 2:40 PM
To: 'Hal Lockhart'; Philip Hallam-Baker; ''Security-Core (E-mail)'
Subject: RE: conference call - March 29

Hal,
 
    I agree, essentially what we get down to is an authentication mechanism based on a shared secret. This is fine for bilateral relationships but does not scale.
 
    When it comes to authenticating the principal in a multi-domain setting the only way I know that scales is to use a credential that does not require the secret to be revealed or pre-shared to demonstrate knowledge of it, i.e. public key.
 
        Phill
 

Phillip Hallam-Baker
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227

-----Original Message-----
From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
Sent: Friday, March 30, 2001 2:31 PM
To: 'Philip Hallam-Baker'; ''Security-Core (E-mail)'
Subject: RE: conference call - March 29

In the 0.3 version of the document, I am unclear about the box at the top of page 11 that starts "Alternate means of identifying the assertion" Are these design alternatives or are you proposing to support a number of different ways of identifying the same assertion?
 
Without regard to the answer to that question, have you considered the alternative of using tickets which are simple references and contain no information in themselves? For example, create a random number X, use the hash of X as the assertion id, put the domain and X in a cookie (or wherever).
 
The problem with using a reversible encryption of the ticket is that given that SAML will be used for interop between a large number of independant orgs, the key will be a) potentially known to a lot of people and b) hard to change. Unless we invent some key management protocol this will make it easy for attackers to spoof tickets.
 
Hal
-----Original Message-----
From: Philip Hallam-Baker [mailto:pbaker@verisign.com]
Sent: Wednesday, March 28, 2001 4:04 PM
To: Philip Hallam-Baker; ''Security-Core (E-mail)'
Subject: RE: conference call - March 29

All,
 
    I am still working on the attached trying to get it into some sort of shape. Problem is trying not to spend time writing stuff that should flow from the use cases and requirements.
 
    I'll try to get a version 0.4 for tommorow.
 
        Phill
 

Phillip Hallam-Baker
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227

-----Original Message-----
From: Philip Hallam-Baker [mailto:pbaker@verisign.com]
Sent: Tuesday, March 27, 2001 2:41 PM
To: ''Security-Core (E-mail)'
Subject: FW: conference call - March 29


March 29th
12pm EST

Running time :appx. 1 hour
Confirmation # 8532838
Dial in number : 1.904.779.4702

 



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


Powered by eList eXpress LLC